On 2/26/19 7:48 PM, Richard Biener wrote:
> On February 26, 2019 6:50:13 PM GMT+01:00, "Martin Liška"
> wrote:
>> On 2/26/19 4:02 PM, Richard Biener wrote:
>>> On Tue, Feb 26, 2019 at 3:30 PM Martin Liška wrote:
Hi.
I've rewritten bitmap memory statistics which abused unsigne
On Tue, 26 Feb 2019, Jakub Jelinek wrote:
> Hi!
>
> Seems valid_constant_size_p has been written with the expectation that only
> sizetype/ssizetype constants will be passed to it, otherwise it couldn't
> ever just blindly test tree_int_cst_sign_bit (size) for unsigned
> INTEGER_CSTs and complain
On Tue, 26 Feb 2019, Jakub Jelinek wrote:
> On Tue, Feb 26, 2019 at 05:18:17PM +0100, Jakub Jelinek wrote:
> > > > Shall I modify the patch for that?
> > >
> > > Might it even simplify the patch? If not the only comment on the
> > > original patch is that it would be nice to test it on a SJLJ EH
This fixes inconsistencies with respect to computing DIE sizes and
abbrevs when using -fdebug-types-section and LTO where we have
external refs that are _not_ refs to comdat_type_p's. output_die
gets this correct but both size_of_die and value_format simply
key on use_debug_types which causes th
This makes -fdebug-types-section actually work with -flto, causing
type units to be created and referred to by early debug.
I've lightly tested the result with hello-world style examples
where before this patch gdb wasn't able to see any types
(there were signature refs but the type units were m
Ping.
Thanks,
Kyrill
On 2/15/19 11:52 AM, Kyrill Tkachov wrote:
Ping.
https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00345.html
Thanks,
Kyrill
On 2/6/19 1:52 PM, Kyrill Tkachov wrote:
[resending with patch compressed]
Hi all,
We're somewhat inconsistent in arm_neon.h when it comes to us
Add myself to write after approval.
Alejandro
Committed to trunk in r 269246
Index: MAINTAINERS
===
--- MAINTAINERS(revision 269244)
+++ MAINTAINERS(working copy)
@@ -495,6 +495,7 @@
Jose E. Marchesi
Patrick
On Sun, Feb 10, 2019 at 6:21 PM Jan Hubicka wrote:
>
> Hi,
> build_qualified_type adjusts alignment of atomic types to one of minimal
> alignment needed for atomic operations (I think it does so). For packed
> structures this leads to type variant to be created and alignment to be
> updated later.
On Wed, Feb 27, 2019 at 9:01 AM Martin Liška wrote:
>
> On 2/26/19 7:48 PM, Richard Biener wrote:
> > On February 26, 2019 6:50:13 PM GMT+01:00, "Martin Liška"
> > wrote:
> >> On 2/26/19 4:02 PM, Richard Biener wrote:
> >>> On Tue, Feb 26, 2019 at 3:30 PM Martin Liška wrote:
>
> Hi.
>
On Mon, Feb 25, 2019 at 10:23:52AM +, Kyrill Tkachov wrote:
> > The only bootstraps I'm doing are distro builds with
> > --with-tune=generic-armv7-a --with-arch=armv7-a \
> > --with-float=hard --with-fpu=vfpv3-d16 --with-abi=aapcs-linux
> > I don't have setup nor experience wi
Certain broken versions of xsltproc ignore the --nonet option and will
attempt to fetch the docbook stylesheet from the WWW when it isn't in
the local XML catalog.
This patch checks for the local stylesheet directory first, and doesn't
use xsltproc if no local stylesheets are found. Checking for
On 27/02/2019 10:56, Jakub Jelinek wrote:
> On Mon, Feb 25, 2019 at 10:23:52AM +, Kyrill Tkachov wrote:
>>> The only bootstraps I'm doing are distro builds with
>>> --with-tune=generic-armv7-a --with-arch=armv7-a \
>>> --with-float=hard --with-fpu=vfpv3-d16 --with-abi=aapcs-li
Hi,
in the discussion in PR 87525 Honza noted that IPA-CP should not
estimate any local time benefits from cloning an extern inline function,
that any benefits this might bring about have to come from other
specializations such cloning might enable.
While the patch is only a heuristics change and
This avoids .debug_types for the late debug where we shouldn't emit
any type DIEs anyway. This follows the recent change for pubnames.
Bootstrap & regtest running on x86_64-unknown-linux-gnu.
2019-02-27 Richard Biener
PR debug/88878
* dwarf2out.c (use_debug_types): Disable
Hi.
The patch adds missing information into JSON intermediate format.
Before the patch one can't assign 'lines' to 'functions' in case
one has a group function (e.g. a template function).
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I will install it if not objections.
Ping.
> -Original Message-
> From: Tamar Christina
> Sent: Thursday, February 7, 2019 10:43
> To: Tamar Christina ; Jakub Jelinek
>
> Cc: Kyrill Tkachov ; gcc-patches@gcc.gnu.org;
> nd ; James Greenhalgh ;
> Richard Earnshaw ; Marcus Shawcroft
>
> Subject: RE: [PATCH][GCC][AArch64] Have
Turns out the cgraph code isn't happy if cgraph edge (re-)building
is skipped.
Tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2019-02-27 Richard Biener
* passes.c (should_skip_pass_p): Do not skip cgraph-edge
building.
* gcc.dg/gimplefe-36.c: New te
CFG cleanup is now set up to perform trivial unreachable code
elimination before doing anything that would require up-to-date
SSA form. Unfortunately a pending SSA update still will cause
breakage to stmt folding triggered for example by basic-block
merging.
Fortunately it's now easy to properl
On 2/27/19 11:45 AM, Richard Biener wrote:
> On Wed, Feb 27, 2019 at 9:01 AM Martin Liška wrote:
>>
>> On 2/26/19 7:48 PM, Richard Biener wrote:
>>> On February 26, 2019 6:50:13 PM GMT+01:00, "Martin Liška"
>>> wrote:
On 2/26/19 4:02 PM, Richard Biener wrote:
> On Tue, Feb 26, 2019 at 3
Hi Jakub,
On 2/27/19 10:56 AM, Jakub Jelinek wrote:
On Mon, Feb 25, 2019 at 10:23:52AM +, Kyrill Tkachov wrote:
The only bootstraps I'm doing are distro builds with
--with-tune=generic-armv7-a --with-arch=armv7-a \
--with-float=hard --with-fpu=vfpv3-d16 --with-abi=aapcs-
On Wed, Feb 27, 2019 at 02:43:01PM +, Kyrill Tkachov wrote:
> As discussed on IRC, I've bootstrapped and tested this on
> arm-none-linux-gnueabihf.
Thanks for doing that. I've committed the config/arm/ changes, they really
don't depend on the aarch64 changes or vice versa.
> So from an arm p
On Wed, Feb 27, 2019 at 12:20 AM Richard Biener wrote:
>
> On Tue, 26 Feb 2019, Jakub Jelinek wrote:
>
> > On Tue, Feb 26, 2019 at 05:18:17PM +0100, Jakub Jelinek wrote:
> > > > > Shall I modify the patch for that?
> > > >
> > > > Might it even simplify the patch? If not the only comment on the
>
On Wed, Feb 27, 2019 at 07:03:06AM -0800, H.J. Lu wrote:
> I got
>
> FAIL: gcc.dg/torture/pr57147-2.c -O1 scan-tree-dump-not optimized "setjmp"
> FAIL: gcc.dg/torture/pr57147-2.c -O2 -flto -fno-use-linker-plugin
> -flto-partition=none scan-tree-dump-not optimized "setjmp"
> FAIL: gcc.dg/to
On Sat, Feb 16, 2019 at 8:26 AM Eric Botcazou wrote:
>
> This gets rid of a bunch of Go failures on SPARC.
>
> Tested on x86-64/Linux, SPARC/Solaris and SPARC64/Linux.
>
>
> 2019-02-16 Eric Botcazou
>
> * go/runtime/malloc.go (persistentalloc1): Always align the offset.
Thanks, committ
On 2/26/19 5:13 PM, Marek Polacek wrote:
Here we ICE because the unscoped enum's context is a FUNCTION_DECL, which
push_using_decl can't handle.
http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#1742
says this is well-formed (but the scoped enum case is ill-formed).
Nevertheless, the D
On Fri, Feb 22, 2019 at 06:20:51PM -0600, Jakub Jelinek wrote:
> Hi!
>
> The testcase in the PR doesn't hoist any memory loads from the large switch
> before the switch on aarch64 and arm (unlike e.g. x86), because the
> arm/aarch64 casesi patterns don't properly annotate the memory load from the
On Wed, Feb 27, 2019 at 10:53:16AM -0500, Jason Merrill wrote:
> On 2/26/19 5:13 PM, Marek Polacek wrote:
> > Here we ICE because the unscoped enum's context is a FUNCTION_DECL, which
> > push_using_decl can't handle.
> >
> > http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#1742
> > say
On Thu, Feb 07, 2019 at 04:43:24AM -0600, Tamar Christina wrote:
> Hi All,
>
> Since this hasn't been reviewed yet anyway I've updated this patch to also
> fix the memory leaks etc.
>
> --
>
> This patch makes the feature detection code for AArch64 GCC not add features
> automatically when the
Hi James,
> -Original Message-
> From: James Greenhalgh
> Sent: Wednesday, February 27, 2019 17:22
> To: Tamar Christina
> Cc: Jakub Jelinek ; Kyrill Tkachov
> ; gcc-patches@gcc.gnu.org; nd
> ; Richard Earnshaw ; Marcus
> Shawcroft
> Subject: Re: [PATCH][GCC][AArch64] Have empty HWCAPs
On Wed, Feb 27, 2019 at 11:49 AM Marek Polacek wrote:
> On Wed, Feb 27, 2019 at 10:53:16AM -0500, Jason Merrill wrote:
> > On 2/26/19 5:13 PM, Marek Polacek wrote:
> > > Here we ICE because the unscoped enum's context is a FUNCTION_DECL, which
> > > push_using_decl can't handle.
> > >
> > > http:/
Ping^3?
On Wed, Feb 13, 2019 at 4:28 PM Jason Merrill wrote:
>
> Ping^2
>
> On Mon, Feb 4, 2019 at 4:09 PM Jason Merrill wrote:
> >
> > Ping
> >
> > On Fri, Jan 25, 2019 at 10:06 AM Jason Merrill wrote:
> > >
> > > Here we warn because i::dispatch has internal linkage (because l
> > > does) and
On Wed, Feb 27, 2019 at 01:43:12PM -0500, Jason Merrill wrote:
> On Wed, Feb 27, 2019 at 11:49 AM Marek Polacek wrote:
> > On Wed, Feb 27, 2019 at 10:53:16AM -0500, Jason Merrill wrote:
> > > On 2/26/19 5:13 PM, Marek Polacek wrote:
> > > > Here we ICE because the unscoped enum's context is a FUNC
On Wed, Feb 27, 2019 at 1:48 PM Marek Polacek wrote:
>
> On Wed, Feb 27, 2019 at 01:43:12PM -0500, Jason Merrill wrote:
> > On Wed, Feb 27, 2019 at 11:49 AM Marek Polacek wrote:
> > > On Wed, Feb 27, 2019 at 10:53:16AM -0500, Jason Merrill wrote:
> > > > On 2/26/19 5:13 PM, Marek Polacek wrote:
>
Hi!
This patch fixes a P1 regression due to the recently introduced
more aggressive constant string merging, which does not work
correctly in object blocks consisting of STRING_CST w/o proper
zero-termination.
Fixed by avoiding creation of block objects for objects located
in mergeable sections.
On Wed, Feb 27, 2019 at 07:44:40PM +, Bernd Edlinger wrote:
> This patch fixes a P1 regression due to the recently introduced
> more aggressive constant string merging, which does not work
> correctly in object blocks consisting of STRING_CST w/o proper
> zero-termination.
>
> Fixed by avoidin
Latest results for 6.x.
-tgc
Testresults for 6.5.0:
hppa2.0w-hp-hpux11.11
hppa64-hp-hpux11.11
powerpc64le-unknown-linux-gnu
powerpc64-unknown-linux-gnu
x86_64-w64-mingw32
--- /home/tgc/projects/gcc/wwwdocs/htdocs/gcc-6/buildstat.html 2019-02-27
18:33:53.555978983 +0100
+++ /tmp/tmp.l
Latest results for 7.x.
-tgc
Testresults for 7.4.0:
x86_64-w64-mingw32
--- /home/tgc/projects/gcc/wwwdocs/htdocs/gcc-7/buildstat.html 2019-02-27
18:33:53.559979051 +0100
+++ /tmp/tmp.fa3s1NLqiV 2019-02-27 21:38:18.452766358 +0100
@@ -126,6 +126,7 @@
x86_64-w64-mingw32
Test results:
+htt
build_value_init doesn't work in templates (for non-scalar/array types,
anyway), so avoid this situation, much like in build_new_method_call_1.
We're calling convert_like_real because when there's only one non-viable
candidate function, build_new_function_call calls cp_build_function_call_vec
to g
Here, the problem was that extract_local_specs wasn't seeing that we use
'self' inside the lambda in the else of the inner constexpr if, because we
don't walk into lambda bodies and we didn't capture it in the lambda because
'self' is still dependent. Marek recently changed process_outer_var_ref t
This patch changes libgo to handle function descriptors correctly.
When using PPC64 ELF ABI v1 a function address is not a PC, but is the
address of a function descriptor. The first field in the function
descriptor is the actual PC (see
http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.ht
Hi!
C++ before 2a says that constexpr constructors may not have function-try-block
body, for other constexpr functions it instead says that the function body
can be (=delete, =default or compound-statement), but that rules out
function-try-block as well.
For ctors we were diagnostic this in
build
Hi!
convert.c doesn't verify the CALL_EXPRs to builtin functions have exactly
one argument (and a scalar float one) and can ICE if that is not the case
due to K&R declarations of the library functions and passing too few
arguments.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-lin
Hi!
As the following testcase shows, with -w we don't emit
-Wbuiltin-declaration-mismatch warnings (correct), but emit weird messages:
~/src/gcc/obj46/gcc/xgcc -B ~/src/gcc/obj46/gcc/ -w pr89525.c -S
pr89525.c: In function ‘foo’:
pr89525.c:5:8: note: declared here
5 | double sqrt (); /* { dg-
Adding -Wsurprising as option to gfortran exercised a code path
that I hadn't seen when working on simplifications for the TRANSFER
intrinsic. While regtesting, I realized that one of the checks was
too strict when the MOLD argument was scalar and of size 0 and should
only apply to array arguments
On 2/27/19 4:22 PM, Marek Polacek wrote:
build_value_init doesn't work in templates (for non-scalar/array types,
anyway), so avoid this situation, much like in build_new_method_call_1.
We're calling convert_like_real because when there's only one non-viable
candidate function, build_new_function
On 2/27/19 5:37 PM, Jakub Jelinek wrote:
Hi!
C++ before 2a says that constexpr constructors may not have function-try-block
body, for other constexpr functions it instead says that the function body
can be (=delete, =default or compound-statement), but that rules out
function-try-block as well.
On Tue, Feb 26, 2019 at 08:13:32PM -0700, Jeff Law wrote:
> My point is we see this stuff all the time on common platforms with
> simple -O2 optimization. It deleted something like 2k dead insns on an
> x86_64 bootstrap before I added goof'd up trap_p test. What I don't
> have a sense of is how o
On Wed, 27 Feb 2019, Jakub Jelinek wrote:
> Hi!
>
> convert.c doesn't verify the CALL_EXPRs to builtin functions have exactly
> one argument (and a scalar float one) and can ICE if that is not the case
> due to K&R declarations of the library functions and passing too few
> arguments.
>
> Fixed
On Wed, 27 Feb 2019, Jakub Jelinek wrote:
> Hi!
>
> As the following testcase shows, with -w we don't emit
> -Wbuiltin-declaration-mismatch warnings (correct), but emit weird messages:
> ~/src/gcc/obj46/gcc/xgcc -B ~/src/gcc/obj46/gcc/ -w pr89525.c -S
> pr89525.c: In function ‘foo’:
> pr89525.c:
On Thu, Feb 21, 2019 at 1:47 AM Andreas Schwab wrote:
>
> On Feb 20 2019, Ian Lance Taylor wrote:
>
> > if test x$hasoutput = xtrue; then
> > - echo ' {"'$n'", '$j', "'"$output"'", '$unordered'},'
> > + echo ' {"'$n'", '$j', "'"$(cat example
This patch by Nikhil Benesch uses the correct go_export section name
when building on Darwin. The Darwin build doesn't actually work, but
this should make it a tiny bit better. Bootstrapped on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
Hi!
I am looking to see if there would be any support for a patch introducing an
option to the compiler for ARM to allow for generation of code using TPIDRURW
(the user-writable thread ID register in CP15) as the thread ID instead of
TPIDRURO.
Currently, GCC claims to support using CP15 for th
52 matches
Mail list logo
