On 09/10/19 16:29 -0400, Marek Polacek wrote:
On Wed, Oct 09, 2019 at 11:01:39AM +0100, Jonathan Wakely wrote:
On 07/10/19 14:56 -0400, Jason Merrill wrote:
> On 10/7/19 1:42 PM, Marek Polacek wrote:
> > @@ -7401,8 +7432,20 @@ convert_like_real (conversion *convs, tree expr,
tree fn, int argnum
Hi!
The following patch adds parsing support for #pragma omp declare variant.
The contexts are kept in attributes and nothing is done with them so far,
later on I'll need to add support for determining whether a context selector
matches the current context (will need several modes, some done in th
On Mon, Oct 07, 2019 at 05:17:56PM -0400, Jason Merrill wrote:
> Ah, I see. And it occurs to me this situation fails condition #1 for
> get_formal_tmp_var anyway. So I guess the predicate direction doesn't make
> sense. Let's factor out the above pattern differently, then. Maybe a
> preevaluate
Hi Thomas,
On 10/10/19 12:23 AM, Thomas Koenig wrote:
+ if (s->ts.type == BT_CLASS || s->as->type == AS_ASSUMED_SHAPE
+ || s->attr.pointer)
+ return false;
dt%foo – again, "foo" can be an allocatable of polymorphic type or a
pointer, but at least, it cannot be of assumed shape.
Rea
On Wed, 9 Oct 2019, co...@sdf.org wrote:
> diff --git a/gcc/testsuite/gcc.c-torture/compile/pr85401-2.c
> b/gcc/testsuite/gcc.c-torture/compile/pr85401-2.c
> new file mode 100644
> index 000..1d68d0b
> --- /dev/null
> +++ b/gcc/testsuite/gcc.c-torture/compile/pr85401.c
> @@ -0,0 +1,18 @@
> +/
Jim Wilson writes:
> This addresses PR 91860 which has four testcases triggering internal errors.
> The problem here is that in combine when handling debug insns, we are trying
> to substitute
> (sign_extend:DI (const_int 8160 [0x1fe0]))
> as the value for
> (reg:DI 78 [ _9 ])
> in the debug insn
Committed as obvious (r276791) – cherry picked from the patch (still
awaiting review):
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00503.html
("[patch][OpenMP,Fortran] Fix several OpenMP use_device_addr/map/update
errors found by a length test case")
Tobias
PS: This bit was missing from th
So far z15 was identified as arch13. After the machine has been
announced we can now add the real name.
gcc/ChangeLog:
2019-10-10 Andreas Krebbel
* common/config/s390/s390-common.c (PF_ARCH13): Rename to...
(PF_Z15): ... this.
* config.gcc: Add z15 as option for --with
For the call to __morestack we use a special ABI in the S/390 back-end
which requires us to emit a parameter block to the .rodata section
which contains the label whereto __morestack needs to return. The
parameter block needs to be explicit in RTL since we also need the
address of it loaded into r
Hopefully an obvious amendment.
Will test out the new git repo soon!
Thanks,
Kyrill
commit ddf1524244ac30ab3473d0df6d8e76d5c9a42276
Author: Kyrylo Tkachov
Date: Wed Oct 9 16:15:00 2019 +0100
[gcccmission.html] Replace cvs with version control
diff --git a/htdocs/gccmission.html b/htdo
On Thu, Oct 10, 2019 at 09:41:35AM +0100, Maciej W. Rozycki wrote:
> On Wed, 9 Oct 2019, co...@sdf.org wrote:
>
> > diff --git a/gcc/testsuite/gcc.c-torture/compile/pr85401-2.c
> > b/gcc/testsuite/gcc.c-torture/compile/pr85401-2.c
> > new file mode 100644
> > index 000..1d68d0b
> > --- /dev/n
Kyrill Tkachov writes:
> Hopefully an obvious amendment.
>
> Will test out the new git repo soon!
>
> Thanks,
>
> Kyrill
>
> commit ddf1524244ac30ab3473d0df6d8e76d5c9a42276
> Author: Kyrylo Tkachov
> Date: Wed Oct 9 16:15:00 2019 +0100
>
> [gcccmission.html] Replace cvs with version control
On 10/10/19 10:18 AM, Richard Sandiford wrote:
Kyrill Tkachov writes:
Hopefully an obvious amendment.
Will test out the new git repo soon!
Thanks,
Kyrill
commit ddf1524244ac30ab3473d0df6d8e76d5c9a42276
Author: Kyrylo Tkachov
Date: Wed Oct 9 16:15:00 2019 +0100
[gcccmission.html]
On Mon, 7 Oct 2019 at 13:53, Aldy Hernandez wrote:
>
> > +bool
> > +ipa_vr::nonzero_p (tree expr_type) const
> > +{
> > + if (type == VR_ANTI_RANGE && wi::eq_p (min, 0) && wi::eq_p (max, 0))
> > +return true;
> > +
> > + unsigned prec = TYPE_PRECISION (expr_type);
> > + return (type == VR_
Hi Joseph,
> On Wed, 9 Oct 2019, Rainer Orth wrote:
>
>> the new test FAILs on Solaris/x86, both 32 and 64-bit:
>>
>> FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c -O0 execution test
>> FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c -O1 execution test
>> FAIL: gcc.dg/torture/builtin-
Hi Kugan,
On 10/10/19 2:55 AM, Kugan Vivekanandarajah wrote:
As reported in Linaro bug report
(https://bugs.linaro.org/show_bug.cgi?id=4636 ; there is no
reproducible testcase provided), for some applications, we see
(insn 126 125 127 9 (set (reg:DF 189)
(fma:DF (reg:DF 126 [ _74 ])
Hi Rainer,
Rainer Orth wrote:
Hi Joseph,
On Wed, 9 Oct 2019, Rainer Orth wrote:
the new test FAILs on Solaris/x86, both 32 and 64-bit:
FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c -O0 execution test
FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c -O1 execution test
FAIL: gcc.
Hi,
On Wed, Oct 09 2019, Richard Biener wrote:
>>
...
>> + /* If we only have the fntype extracted from the call statement, check it
>> + against the type of declarations while being pessimistic about
>> + promotions. */
>> + tree p;
>> +
>> + if (fndecl)
>> +p = TYPE_ARG_TYPES (
Hi Kyrill,
On 10/10/2019 10:53, Kyrill Tkachov wrote:
I'm a bit surprised that TARGET_FMA (which just checks isa_bit_vfpv4)
doesn't imply TARGET_VFP_DOUBLE.
Can one really have a VFPV4 single-precision-only configuration? Richard?
Armv7e-M supports single precision only FPv4, which also
Hi Andre,
On 10/10/19 11:28 AM, Andre Vieira (lists) wrote:
Hi Kyrill,
On 10/10/2019 10:53, Kyrill Tkachov wrote:
>
>
> I'm a bit surprised that TARGET_FMA (which just checks isa_bit_vfpv4)
> doesn't imply TARGET_VFP_DOUBLE.
> Can one really have a VFPV4 single-precision-only configuration?
R
Committed to ARM/arm-9-branch
On Wed, Sep 11, 2019 at 4:50 PM Wilco Dijkstra wrote:
>
> While code hoisting generally improves codesize, it can affect performance
> negatively. Benchmarking shows it doesn't help SPEC and negatively affects
> embedded benchmarks, so only enable code hoisting with
Hi all,
I noticed when reading the documentation that BREAK_FROM_IMM_USE_SAFE
was removed at some point in 2006 and replaced with BREAK_FROM_IMM_USE_STMT.
2019-10-10 Joel Hutton joel.hut...@arm.com
* doc/tree-ssa.texi: Update renamed macro name.
From a9569599ee885842eabc6cc22e718486ceb70
This rejects vector constants from the constant pool, which removes
unnecessary reloads of zero constant around function call in the test
case.
Tested with mips-mti-linux-gnu.
gcc/ChangeLog:
* config/mips/mips.c (mips_cannot_force_const_mem): Reject
vector constants.
gcc/testsui
Hi,
I would love to provide a guest contribution to your blog.
Let me know what you think. I'm excited to hear back from you!
Keep Up The Good Work.
Best,
Harsh
Hi Iain,
> Rainer Orth wrote:
>
>> Hi Joseph,
>>
>>> On Wed, 9 Oct 2019, Rainer Orth wrote:
>>>
the new test FAILs on Solaris/x86, both 32 and 64-bit:
FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c -O0 execution test
FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c -O
Hi Rainer,
Rainer Orth wrote:
Rainer Orth wrote:
No idea about Darwin/PowerPC though.
Right now, anything < 10.4 is not a viable host (without jumping through
a lot of hoops, regardless of the c99 requirements)...
… but It would be good to continue to support these earlier versions as
On Tue, Oct 08, 2019 at 01:11:53AM +0200, Tobias Burnus wrote:
> gcc/fortran/
> * f95-lang.c (LANG_HOOKS_OMP_IS_ALLOCATABLE_OR_PTR): Re-define to
> gfc_omp_is_allocatable_or_ptr.
> * trans-decl.c (create_function_arglist): Set GFC_DECL_OPTIONAL_ARGUMENT
> only if not p
Hi Iain,
>>> I’m not quite sure what you’re proposing here (probably missing something
>>> obvious).
>>
>> At the moment, gcc/testsuite/lib/target-supports.exp
>> (add_options_for_c99_runtime) adds -mmacosx-version-min=10.3 to the
>> testcase flags on powerpc-*-darwin*. Since, as Joseph mentioned
In addressing 91770, I need to emit a warning for a location inside a
system header file[1]. The diagnostics machinery elides warnings when
the location is in a system header :(
As I happen to have located the appropriate line_map in the process of
determining the nested extern "C", I could c
On Thu, Oct 10, 2019 at 08:24:29AM -0400, Nathan Sidwell wrote:
> In addressing 91770, I need to emit a warning for a location inside a system
> header file[1]. The diagnostics machinery elides warnings when the location
> is in a system header :(
>
> As I happen to have located the appropriate l
Now also to the list...
On Thu, 10 Oct 2019, Richard Biener wrote:
> On Thu, 10 Oct 2019, Martin Jambor wrote:
>
> > Hi,
> >
> > On Wed, Oct 09 2019, Richard Biener wrote:
> > >>
> >
> > ...
> >
> > >> + /* If we only have the fntype extracted from the call statement,
> > >> check it
> >
Hi,
enabling inlining triggered lifetime-dse issue with symbol_table
constructor.
Bootstrapped/regtested x86_64-linux
* cgraph.c (symbol_table_test::symbol_table_test): Use ggc_alloc
rather than ggc_alloc_cleared to alloc symbol table.
* toplev.c (general_init): Likewise.
Hi,
After all the discussions and respins I now believe this patch is close
to what we envisioned.
This patch achieves two things when vect-epilogues-nomask=1:
1) It analyzes the original loop for each supported vector size and
saves this analysis per loop, as well as the vector sizes we know
The following fixes a few param adjustments that are made based on
per-function adjustable flags by moving the adjustments to their
users. Semantics change in some minor ways but that's allowed
for --params.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2019-10-10 Ri
comp_ptr_ttypes_real could use bool instead of int since it only returns
0 or 1.
Bootstrapped/regtested on x86_64-linux, applying to trunk.
2019-10-10 Marek Polacek
* typeck.c (comp_ptr_ttypes_real): Change the return type to bool.
Use false instead of 0.
diff --git gcc/cp/ty
Hi,
this fixes a crash when -Wshadow=compatible-local is
enabled in the testcase g++.dg/parse/crash68.C
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
patch-pr92024.diff
Description: patch-pr92024.diff
It's not that particular commit, but the previous one, but yeah, that's
all me.
(gdb)
#4 0x0145bf44 in value_range_base::lower_bound
(this=0x7fffc360,
pair=0) at /home/cygnus/aldyh/src/gcc/gcc/tree-vrp.c:6148
6148 return wi::to_wide (t);
(gdb)
#5 0x01ccb1d9 in ra
This patch fixes a bug in which a call such as
Some_Map.Replace(10, Some_Map(5)) fails a tampering check. This happens
with the Some_Map(5) notation, or with the equivalent explicit call to
Constant_Reference. A call to Some_Map.Delete(10, Some_Map(5)) fails in
the same way. Other children of Ada.C
Compilation_Unit pragmas that appear after the corresponding unit are
analyzed before the declarations in the unit, in order to set proper
categorization flags and verify that they are respected by those
declarations. If the unit is a child unit and also the instance of a
generic child unit the par
A constant of pointer type is considered as mutable in SPARK, according
to SPARK RM 3.10, but this should be based on the declared type of the
constant instead of its underlying type.
This rule has been already reflected in a recent commit for the Depends
contract; this commit is for the Global co
This patch fixes a bug in which an 'others' array aggregate in a
dependent_expression of a conditional_expression is rejected, even in
cases where 'others' is legal. See RM-4.3.3(15.1).
Running this command:
gcc -c others_test.ads
On the following sources:
package Others_Test is
X : Strin
If a pragma Compile_Time_Error contains T'Size, then T'Size can be
computed as 0 instead of the correct value, causing missing or extra
error messages. The same applies to pragma Compile_Time_Warning. This
patch fixes that bug.
Running these commands:
gcc -c -g -O0 -gnata fillers-neq_error.ads
Analyze_Number_Declaration contains a fast track for the case where the
expression of an integer named number is a literal, but it fails to set
the Debug_Info_Needed flag on the named number.
No functional changes.
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-10-10 Eric Botcazou
gc
Correct an issue where ghost code will set the flag Sec_Stack_Used even
though the code will be eliminated and result in the program not using
the secondary stack. This could confuse the binder into importing
objects from System.Secondary_Stack even though that package is not in
the program's closu
In the case where the tyoe of the formal has a predicate, the compiler
generates a freeze node for the actual subtype of the formal that is
placed just before the declaration of that subtype. No big deal, but
awkward enough as to warrant a correction. No functional changes.
Tested on x86_64-pc-l
This patch fixes a spurious error when expanding the code for a function
that appears in a Ghost context, when return return type of the function
is unconstrainedm and the restriction No_Secondary_Stack is active.
Running this command:
gcc -c repro_main.adb
On the following sources:
with Boun
Compiler rejects a formal package in a generic unit, when the
corresponding generic package includes the SPARK aspect Abstract_State,
and the name introduced by the aspect is referenced in the generic
package.
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-10-10 Ed Schonberg
gcc/ada/
Subprograms with a parameter or function result with deep type should
not be inlined in the special mode for GNATprove, as inlining may lead
to spurious violations of SPARK borrow-checking rules for pointers.
There is no impact on compilation and thus no test.
Tested on x86_64-pc-linux-gnu, commi
Freeze_Subprogram has special handling of C++ constructor interfacing.
This is currently implicit but assuming we introduce other conventions
(e.g. Java) the current code won't hold.
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-10-10 Arnaud Charlet
gcc/ada/
* freeze.adb (Fr
For GNAT-LLVM, we now wrap top-level loop statements in library package
declaration lists within a procedure when there are nested subprograms
within the loop that might make up-level references to entities of the
loop (or to entities of loops and blocks nested within the outer loop
for that matter
A pragma Assertion_Policy (Ignore) was ignored with respect to
invariants; invariants are checked even in the presence of this pragma.
This patch fixes that bug.
Running these commands:
gcc -S -fverbose-asm -g ess-main.adb -gnata
grep Invariant ess-main.s
On the following sources:
pragma As
In the special inlining done for GNATprove, subprograms with parameters
or result of deep type (i.e. containing an access type) should not be
inlined. This was the purpose of a previous patch. But this should not
be applied to private types whose completion has SPARK_Mode Off, as
these types are no
Pragma Preelaborable_Initialization is added to type File_Type in
package Ada.Streams.Stream_IO, per the Binding Interpretation of
AI12-0102. No other source or tool changes are required.
No test needed.
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-10-10 Gary Dismukes
gcc/ada/
For compilers such as GNAT-LLVM that requiring unnesting of subprograms
that make up-level references, the GNAT front end needs to check for
block statements occurring within elaboration of library-level packages,
and transform those into procedures that can be passed an
activation-record parameter
The case of a protected entry family body with a nested subprogram
wasn't recognized for purposes of unnesting, leading to unhandled
up-level references, because Has_Nested_Subprogram was incorrectly
returning False. This was due to Set_Has_Nested_Subprogram not being
called on the procedure create
If the exprsssion in an expression function includes a function call
with an out-parameter, the corresponding assignment may be flagged as
redundant because it is analyzed twice, once in the expression function
and once in the body constructed for it.
Running this command:
gcc -c -gnatg warn.ad
This prevents the compiler from issuing a spurious error for the _Tag
component of a tagged record extension if the parent type has a
Bit_Order clause specifying the reverse order and a component clause.
The cause is a simple off-by-one bug in the artificial component clause
synthetized for the _Ta
Hi,
When we did the refactoring of SH's FPSCR handling back in GCC 5, we
missed one thing regarding ST-40, it seems.
The attached patch fixes the issue as confirmed on the real hardware.
Also tested on sh-sim with
make -k check RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb,-
m2a/-mb,-m4/-
Hi,
while working on cp_build_binary_op I noticed that the testsuite wasn't
exercising the warnings in case RROTATE_EXPR / LROTATE_EXPR, even more
the code handling those tree codes seemed completely unused. Turned out
that the C front-end doesn't handle those tree codes at all: I'm coming
to
We have to handle (skip) DEBUG_INSN in alpha_handle_trap_shadows.
2019-10-10 Uroš Bizjak
PR target/92022
* config/alpha/alpha.c (alpha_handle_trap_shadows): Skip DEBUG_INSN.
testsuite/ChangeLog:
2019-10-10 Uroš Bizjak
PR target/92022
* g++.dg/pr92022.C: New test.
Bootstr
On 09/10/19 16:59 +0100, Jonathan Wakely wrote:
If two threads see _M_index==0 concurrently they will both try to set
it, potentially storing the facet at two different indices in the array.
Either set the _M_index data member using an atomic compare-exchange
operation or while holding a mutex.
Hi Jakub,
On 10/10/19 1:55 PM, Jakub Jelinek wrote:
What worries me about the test is that the officially only portable way
to use it in a target region is is_device_ptr.
How about the attached test cases? The only difference is in "module
target_procs".
OK now?
Still, I hope the next rou
On Thu, Oct 10, 2019 at 06:49:52PM +0200, Tobias Burnus wrote:
> On 10/10/19 1:55 PM, Jakub Jelinek wrote:
> > What worries me about the test is that the officially only portable way
> > to use it in a target region is is_device_ptr.
>
> How about the attached test cases? The only difference is in
On Thu, Oct 10, 2019 at 7:50 PM Tobias Burnus wrote:
>
> Hi Jakub,
>
> On 10/10/19 1:55 PM, Jakub Jelinek wrote:
> > What worries me about the test is that the officially only portable way
> > to use it in a target region is is_device_ptr.
>
> How about the attached test cases? The only difference
This patch uses the support for pretty-printing escaped URLs added in
the previous patch (PR 87488) so that in a sufficiently capable terminal
the [-Wname-of-option] emitted at the end of each diagnostic becomes a
hyperlink to the documentation for that option on the GCC website.
I've tested it wi
https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
describes an emerging standard for embedding URLs in escape sequences
for marking up text output. This is supported e.g. by recent releases
of GNOME Terminal.
This patch adds support to our pretty-printing framework for emitting
U
Any further comments? Note GCC doesn't support S/UMULLS either since it is
equally
useless. It's no surprise that Thumb-2 removed support for flag-setting 64-bit
multiplies,
while AArch64 didn't add flag-setting multiplies. So there is no argument that
these
instructions are in any way useful to
ping
Contrary to all documentation, SLOW_BYTE_ACCESS simply means accessing
bitfields by their declared type, which results in better codegeneration
on practically any target. So set it correctly to 1 on Arm.
As a result we generate much better code for bitfields:
typedef struct
{
int x : 2,
On Thu, 10 Oct 2019 at 17:19, Aldy Hernandez wrote:
> It's not that particular commit, but the previous one, but yeah, that's
> all me.
Interesting, bisect really identified r276654.
I think that's what Steve reported as PR 92051 (although his backtrace is
different, but it's also for a differe
ping
Contrary to all documentation, SLOW_BYTE_ACCESS simply means accessing
bitfields by their declared type, which results in better codegeneration on
practically
any target.
I'm thinking we should completely remove all trace of SLOW_BYTE_ACCESS
from GCC as it's confusing and useless.
OK for c
ping
In aarch64_classify_symbol symbols are allowed full-range offsets on
relocations.
This means the offset can use all of the +/-4GB offset, leaving no offset
available
for the symbol itself. This results in relocation overflow and link-time
errors
for simple expressions like
ping
Currently the Arm backend selects the alternative sched pressure algorithm.
The issue is that this doesn't take register pressure into account, and so
it causes significant additional spilling on Arm where there are only 14
allocatable registers. SPEC2006 shows significant codesi
ping
Setting HONOR_REG_ALLOC_ORDER improves codesize with -Os, however it generates
slower and larger code with -O2 and higher. So only set it when optimizing for
size. On Cortex-A57 this improves SPECINT2006 by 0.15% and SPECFP2006 by 0.25%
while reducing codesize.
Bootstrap OK, OK for commit?
ping
Currently arm_legitimize_address doesn't handle Thumb-2 at all, resulting in
inefficient code. Since Thumb-2 supports similar address offsets use the Arm
legitimization code for Thumb-2 to get significant codesize and performance
gains. SPECINT2006 shows 0.4% gain on Cortex-A57, while SPECF
On 10/10/19 12:12 PM, Paolo Carlini wrote:
Hi,
while working on cp_build_binary_op I noticed that the testsuite wasn't
exercising the warnings in case RROTATE_EXPR / LROTATE_EXPR, even more
the code handling those tree codes seemed completely unused. Turned out
that the C front-end doesn't ha
Hi David,
While I agree that this is quite cool to have, the following:
+/* DOCUMENTATION_ROOT_URL should be supplied via -D by the Makefile
+ (see --with-documentation-root-url).
+
+ Expect an anchor of the form "index-Wfoo" e.g.
+ , and thus an id within
+ the URL
ping
PR79262 has been fixed for almost all AArch64 cpus, however the example is still
vectorized in a few cases, resulting in lower performance. Increase the cost of
vector-to-scalar moves so it is more similar to the other vector costs. As a
result
-mcpu=cortex-a53 no longer vectorizes the test
On 10/10/19 10:42 AM, Bernd Edlinger wrote:
Hi,
this fixes a crash when -Wshadow=compatible-local is
enabled in the testcase g++.dg/parse/crash68.C
Why does that flag cause this crash?
Jason
This patch is the first of 3 patches to the test framework for the prefixed
(and PC-relative) address support. This patch adds some miscellaneous tests.
It also adds new target supports for prefixed addressing and PC-relative
addressing.
With patches #1-11 installed, these tests all pass. Can I
These tests go through each of the types to make sure the number of expected
prefixed instructions are generated.
With patches #1-12 installed, these tests all pass. Can I install them into
the trunck once pages 1-11 are committed?
2019-10-03 Michael Meissner
* gcc/testsuite/gcc.tar
These tests add tests for PC-relative addressing with the various types.
With patches #1-12 installed, these tests all pass. Can I install them into
the trunk once pages 1-11 are committed?
2019-10-08 Michael Meissner
* gcc/testsuite/gcc.target/powerpc/prefix-pcrel.h: New set of
On Thu, Oct 10, 2019 at 06:12:02PM +0200, Paolo Carlini wrote:
> while working on cp_build_binary_op I noticed that the testsuite wasn't
> exercising the warnings in case RROTATE_EXPR / LROTATE_EXPR, even more the
> code handling those tree codes seemed completely unused. Turned out that the
> C fr
On 10/10/19 4:13 AM, Jakub Jelinek wrote:
On Mon, Oct 07, 2019 at 05:17:56PM -0400, Jason Merrill wrote:
Ah, I see. And it occurs to me this situation fails condition #1 for
get_formal_tmp_var anyway. So I guess the predicate direction doesn't make
sense. Let's factor out the above pattern di
On 10/10/19 1:53 PM, Jakub Jelinek wrote:
On Thu, Oct 10, 2019 at 06:12:02PM +0200, Paolo Carlini wrote:
while working on cp_build_binary_op I noticed that the testsuite wasn't
exercising the warnings in case RROTATE_EXPR / LROTATE_EXPR, even more the
code handling those tree codes seemed comple
In the code gaffe I had with the V4 patches, where I mistakenly did:
PADDI rt,ra,label@pcrel
(which the machine does not support), it was suggested that perhaps I should
add an explicit (0),1 to each @pcrel relocation, so that the assembler will
flag any usage where you try to combine an
On 10/10/19 7:49 PM, Jason Merrill wrote:
> On 10/10/19 10:42 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> this fixes a crash when -Wshadow=compatible-local is
>> enabled in the testcase g++.dg/parse/crash68.C
>
> Why does that flag cause this crash?
>
gcc/cp/name-lookup.c:
if (warn_shadow)
Wilco Dijkstra writes:
> ping
>
> Contrary to all documentation, SLOW_BYTE_ACCESS simply means accessing
> bitfields by their declared type, which results in better codegeneration on
> practically
> any target.
The name is confusing, but the documentation looks accurate to me:
Define this m
On Thu, Oct 10, 2019 at 06:06:40PM +, Bernd Edlinger wrote:
> On 10/10/19 7:49 PM, Jason Merrill wrote:
> > On 10/10/19 10:42 AM, Bernd Edlinger wrote:
> >> Hi,
> >>
> >> this fixes a crash when -Wshadow=compatible-local is
> >> enabled in the testcase g++.dg/parse/crash68.C
> >
> > Why does t
Wilco Dijkstra writes:
> ping
>
> In aarch64_classify_symbol symbols are allowed full-range offsets on
> relocations.
> This means the offset can use all of the +/-4GB offset, leaving no offset
> available
> for the symbol itself. This results in relocation overflow and link-time
>
Hi,
On 10/10/19 19:57, Jason Merrill wrote:
On 10/10/19 1:53 PM, Jakub Jelinek wrote:
On Thu, Oct 10, 2019 at 06:12:02PM +0200, Paolo Carlini wrote:
while working on cp_build_binary_op I noticed that the testsuite wasn't
exercising the warnings in case RROTATE_EXPR / LROTATE_EXPR, even
more t
On Thu, 10 Oct 2019, Kyrill Tkachov wrote:
>> Not sure whether this is supposed to be a living document or just a
>> record of what the mission statement was when egcs became GCC. The
>> date at the top is still 1999-04-22.
> Ah, I hadn't considered that. Good thing I didn't get around to
> com
On Thu, Oct 10, 2019 at 02:34:36PM +0200, Jakub Jelinek wrote:
> On Thu, Oct 10, 2019 at 08:24:29AM -0400, Nathan Sidwell wrote:
> > In addressing 91770, I need to emit a warning for a location inside a system
> > header file[1]. The diagnostics machinery elides warnings when the location
> > is i
Ping
Richard Sandiford writes:
> The current aka diagnostics can sometimes leak internal details that
> seem more likely to be distracting than useful. E.g. on aarch64:
>
> void f (va_list *va) { *va = 1; }
>
> gives:
>
> incompatible types when assigning to type ‘va_list’ {aka ‘__va_list’}
On Thu, Oct 3, 2019 at 4:55 PM H.J. Lu wrote:
>
> Here is the patch to update GCC 9 release note. Is it OK?
>
Here is the same patch for git repo. Is it OK?
Thanks.
--
H.J.
From 5d5ce91669258720bb47b254faa6308db3ebeed4 Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Thu, 10 Oct 2019 11:59:5
For the NeXT 64b ABI, IVAR refs are supposed to be indirected for
Mach-O PIC. Identify them so that we can act as needed. A follow-up
patch implements the indirection.
tested on x86_64-darwin16 and powerpc-darwin9
committed to mainline,
thanks
Iain
gcc/objc/ChangeLog:
2019-10-10 Iain Sandoe
Hi,
this patch fixes code removing summaries in ipa-reference. As a memory
leak it may make sense to backport this to release branches.
Honza
* ipa-reference.c (propagate): Fix releasing of IPA summaries.
Index: ipa-reference.c
Objective C V2 (m64) IVAR offset refs from Apple GCC-4.x have an indirection
for m64 code on PPC (which is the only 64b user for Mach-O PIC). Apple GCC
4.x places the indirections in the .data section, however this seems to have
been unintentional - and we are placing the indirections in the non-l
Hi,
ipa-reference uses splay tree to map DECL_UIDs to trees. On other
places we use hash-maps which are more sutiable.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
* ipa-reference.c: Do not include splay-tree.h
(reference_vars_to_consider): Turn to hash map.
(get_
On Thu, Oct 10, 2019 at 08:00:53PM +0100, Richard Sandiford wrote:
> Ping
>
> Richard Sandiford writes:
> > The current aka diagnostics can sometimes leak internal details that
> > seem more likely to be distracting than useful. E.g. on aarch64:
> >
> > void f (va_list *va) { *va = 1; }
> >
>
Hi,
On Thu, 10 Oct 2019 at 01:44, Romain Geissler
wrote:
> Le mer. 9 oct. 2019 à 19:20, Jason Merrill a écrit :
> >
> > Andrew has done a lot of work to update the GCC implementation of C++
> > concepts to conform to the upcoming C++20 standard, which clarifies,
> > removes, and changes variou
1 - 100 of 125 matches
Mail list logo
