This patch works around the lack of simple-object Mach-O support for
LTO debug. It disables early debug generation for darwin (retaining
the debug setting for the fat part of the LTO objects) which should
result in roughly comparable debug for LTO than before the early LTO
debug support. "roughl
Committed as revision 258097 with a corrections to a pre-existing,
garbled comment (Thanks Dominique!) and to the ChangeLog.
Paul
2018-03-01 Paul Thomas
PR fortran/84538
* class.c (class_array_ref_detected): Remove the condition that
there be no reference after the array reference.
(find_intr
> Le 1 mars 2018 à 09:37, Richard Biener a écrit :
>
> In the PR Dominique says "With the patch the failures (-m32/-m64) went
> down from 1059 to 467" which is a nice improvement. I'm not set up
> to bootstrap on darwin but I expect Dominque did so.
Indeed!
>
> So - ok for trunk?
From my
On Wed, Feb 28, 2018 at 3:20 PM, Richard Sandiford
wrote:
> GCC 6 and 7 would vectorise:
>
> void
> f (unsigned long incx, unsigned long incy,
>float *restrict dx, float *restrict dy)
> {
> unsigned long ix = 0, iy = 0;
> for (unsigned long i = 0; i < 512; ++i)
> {
> dy[iy] += dx
On Wed, Feb 28, 2018 at 6:35 PM, Jeff Law wrote:
> On 02/28/2018 03:43 AM, Richard Biener wrote:
>> On Wed, Feb 28, 2018 at 1:16 AM, Jeff Law wrote:
> [ ... snip ...]
>>>
>>> Anyway, I'd already been looking at 21161 and was aware that the CFG's
>>> we're building in presence of setjmp/longjmp we
The following fixes an ICE that occurs when with -flto you disable
debug at compile-time but enable it at link-time. Then we end up
adding a second DW_AT_type to VLA DIEs - the following guards against
this.
Bootstrap and regtest running on x86_64-unknown-linux-gnu, testing in
progress.
Darwin
Hi.
This is a bit forgotten patch. It handles volatile arguments, which should
not be attempted copied into a function local variable.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready to be installed?
Martin
gcc/ChangeLog:
2017-10-11 Martin Liska
PR
Hi,
This issue was caught with assert checking enabled but is not a
functional bug as XINT(x, 0) happens to overlay INTVAL(x) anyway.
Committed to trunk.
Thanks,
Matthew
gcc/
* config/mips/mips.c (mips_final_prescan_insn): Fix incorrect
XINT with INTVAL.
(mips_final_post
Richard Biener writes:
> On Wed, Feb 28, 2018 at 3:20 PM, Richard Sandiford
> wrote:
>> GCC 6 and 7 would vectorise:
>>
>> void
>> f (unsigned long incx, unsigned long incy,
>>float *restrict dx, float *restrict dy)
>> {
>> unsigned long ix = 0, iy = 0;
>> for (unsigned long i = 0; i < 51
Hi.
I've been running periodically UBSAN bootstrap and as the runtime errors are
not causing failure of compiler I haven't noticed the errors.
Thus I would like to disable UBSAN recovery. Apart from that I'm handling
issue in md5.c where in UBSAN bootstrap we want to do proper pointer alignment.
D
On Thu, Mar 01, 2018 at 12:41:37PM +0100, Martin Liška wrote:
> I've been running periodically UBSAN bootstrap and as the runtime errors are
> not causing failure of compiler I haven't noticed the errors.
> Thus I would like to disable UBSAN recovery. Apart from that I'm handling
> issue in md5.c w
On Thu, Mar 01, 2018 at 12:41:37PM +0100, Martin Liška wrote:
> Hi.
>
> I've been running periodically UBSAN bootstrap and as the runtime errors are
> not causing failure of compiler I haven't noticed the errors.
> Thus I would like to disable UBSAN recovery. Apart from that I'm handling
Uh, I do
On 03/01/2018 12:45 PM, Jakub Jelinek wrote:
> On Thu, Mar 01, 2018 at 12:41:37PM +0100, Martin Liška wrote:
>> I've been running periodically UBSAN bootstrap and as the runtime errors are
>> not causing failure of compiler I haven't noticed the errors.
>> Thus I would like to disable UBSAN recover
Hi,
It seems we have had a bug for some time that causes an ICE and prevents the
MIPS16 library builds from completing but is likely unrelated to MIPS16.
The problem is when we call target_reinit and library functions get created
as shown in the call stack at the end of this message. The first bui
Hi Matthew,
> This issue was caught with assert checking enabled but is not a
> functional bug as XINT(x, 0) happens to overlay INTVAL(x) anyway.
There's an intriguing difference between XINT (x, 0) and XWINT (x, 0)
involved here though, which does not appear to be documented in the
manual, an
On Wed, Feb 28, 2018 at 04:50:39PM -0500, Jason Merrill wrote:
> On Wed, Feb 28, 2018 at 4:19 PM, Marek Polacek wrote:
> > On Wed, Feb 28, 2018 at 10:51:17AM -0500, Jason Merrill wrote:
> >> On Wed, Feb 28, 2018 at 9:32 AM, Marek Polacek wrote:
> >> > On Tue, Feb 27, 2018 at 04:16:31PM -0500, Jas
Committed as 'obvious' in revision 258098.
Paul
2018-03-01 Paul Thomas
PR fortran/84219
* target-memory.c (gfc_interpret_derived): Assert that BT_VOID
components are caf tokens.
(gfc_target_interpret_expr): Treat BT_VOID expressions as
integers.
2018-03-01 Paul Thomas
PR fortran/84219
*
On Thu, Mar 01, 2018 at 12:37:51PM +0100, Martin Liška wrote:
> Hi.
>
> This is a bit forgotten patch. It handles volatile arguments, which should
> not be attempted copied into a function local variable.
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Ready to
This fixes another testcase that shows that our ANTIC iteration can
fail to converge. The fix continues what we did with previous fixes,
avoid spuriously removing stuff from the expression side of the sets.
This time going full-in and allowing multiple expressions for the
same value in the sets.
On Thu, Mar 1, 2018 at 12:38 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Wed, Feb 28, 2018 at 3:20 PM, Richard Sandiford
>> wrote:
>>> GCC 6 and 7 would vectorise:
>>>
>>> void
>>> f (unsigned long incx, unsigned long incy,
>>>float *restrict dx, float *restrict dy)
>>> {
>>>
James Greenhalgh writes:
> On Fri, Aug 04, 2017 at 01:41:22PM +0100, Wilco Dijkstra wrote:
>> To implement -fomit-leaf-frame-pointer, there are 2 places where we need
>> to check whether we have to use a frame chain (since register allocation
>> may allocate LR in a leaf function that omits the fr
Here we were using pow2align as the right operand of <<. But for invalid
alignments pow2align can be -1 which makes the shifting invalid. Fixed by
moving the checking before using pow2align.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2018-03-01 Marek Polacek
PR c++/84639
On Wed, Feb 28, 2018 at 4:04 PM, Paolo Carlini wrote:
> On 28/02/2018 20:20, Jason Merrill wrote:
>>
>> Hmm, the test seems wrong; the diagnostic talks about specializing the
>> arguments, but the actual test is checking whether the enclosing scope
>> is fully specialized. It looks like you'll gi
Ping.
Thanks,
Kyrill
On 19/02/18 11:35, Kyrill Tkachov wrote:
Ping.
https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00649.html
CC'ing Eric and Jeff as the patch contains a simplify-rtx.c component that I'll
need midend approval on.
Thanks everyone for your comments so far.
Kyrill
On 12/02/18
Ramana Radhakrishnan writes:
> This fixes a GCC-8 regression that we accidentally switched off frame
> pointers in the AArch64 backend when changing the defaults in the common
> parts of the code. This breaks an ABI decision that was made in GCC at
> the dawn of the port with respect to having a f
On Thu, Mar 1, 2018 at 9:41 AM, Jason Merrill wrote:
> On Wed, Feb 28, 2018 at 4:04 PM, Paolo Carlini
> wrote:
>> On 28/02/2018 20:20, Jason Merrill wrote:
>>>
>>> Hmm, the test seems wrong; the diagnostic talks about specializing the
>>> arguments, but the actual test is checking whether the en
On Wed, Feb 28, 2018 at 02:01:06PM -0500, Jason Merrill wrote:
> On Wed, Feb 28, 2018 at 8:57 AM, Marek Polacek wrote:
> > On Wed, Feb 28, 2018 at 09:11:24AM -0300, Alexandre Oliva wrote:
> >> Evaluation of constant expressions, such as those passed to
> >> static_assert, ICEd when encountering IM
Finally committed to gcc-7-branch, sorry for doing this so late. I've merged the
two commits into one. Patch attached for reference.
Best regards,
Thomas
On 05/12/17 21:26, Mike Stump wrote:
On Dec 5, 2017, at 12:56 PM, Thomas Preudhomme
wrote:
Thanks, I've tested after the two commits an
On Thu, Mar 1, 2018 at 11:28 AM, Marek Polacek wrote:
> On Wed, Feb 28, 2018 at 02:01:06PM -0500, Jason Merrill wrote:
>> On Wed, Feb 28, 2018 at 8:57 AM, Marek Polacek wrote:
>> > On Wed, Feb 28, 2018 at 09:11:24AM -0300, Alexandre Oliva wrote:
>> >> Evaluation of constant expressions, such as t
...since the latter doesn't guarantee independence by itself.
Tested on aarch64-linux-gnu. OK to install?
Richard
2018-03-01 Richard Sandiford
gcc/
* tree-vect-data-refs.c (vect_analyze_data_ref_dependence)
(vect_analyze_data_ref_access): Use loop->safe_len rather than
gcc.target/arm/copysign_softfloat_1.c's use of arm_arch_v6t2 in
dg-add-option changes the architecture to -march=armv6t2. Since the test
only requires Thumb-2 capable architecture, we just need to add -mthumb
on the command line since arm_thumb2_ok guarantees by definition that
doing that is enoug
We were computing &LOOP_VINFO_MASKS even for bb vectorisation,
which is UB.
Tested on aarch64-linux-gnu. OK to install?
Richard
2018-03-01 Richard Sandiford
gcc/
PR tree-optimization/84634
* tree-vect-stmts.c (vectorizable_store, vectorizable_load): Replace
masks an
Falkor's prefetch tuning structure still carries the L2 cache size value from
early support code. This patch updates it to match the specifications.
Even though the prefetcher is currently disabled for Falkor, we have a patch
waiting for GCC development to reopen that re-enables it, so i take it t
In order to use the __float128 in C++ it's necessary to check if
it is supported in libstdc++ (i.e. via _GLIBCXX_USE_FLOAT128) and if the
compiler enabled its support too, e.g. -mfloat128 or -mno-float128.
2018-03-01 Tulio Magno Quites Machado Filho
PR libstdc++/84654
* include/b
On Thu, 1 Mar 2018, Tulio Magno Quites Machado Filho wrote:
In order to use the __float128 in C++ it's necessary to check if
it is supported in libstdc++ (i.e. via _GLIBCXX_USE_FLOAT128) and if the
compiler enabled its support too, e.g. -mfloat128 or -mno-float128.
Shouldn't we ensure that _GL
On Thu, Mar 1, 2018 at 8:17 AM, Marek Polacek wrote:
> On Wed, Feb 28, 2018 at 04:50:39PM -0500, Jason Merrill wrote:
>> On Wed, Feb 28, 2018 at 4:19 PM, Marek Polacek wrote:
>> > On Wed, Feb 28, 2018 at 10:51:17AM -0500, Jason Merrill wrote:
>> >> On Wed, Feb 28, 2018 at 9:32 AM, Marek Polacek
GCC maintainers:
The following patch is a partial backport of mainline commit 257748 to
remove the vec_vextract4b and vec_vinsert4b support. Note in GCC 7,
vec_vextract4b is still used so only the external definitions,
documentation and testcases are removed for vec_vextract4b. All of the
vec_vi
On Thu, Mar 01, 2018 at 03:47:19PM -0300, Tulio Magno Quites Machado Filho
wrote:
> In order to use the __float128 in C++ it's necessary to check if
> it is supported in libstdc++ (i.e. via _GLIBCXX_USE_FLOAT128) and if the
> compiler enabled its support too, e.g. -mfloat128 or -mno-float128.
>
>
In this testcase we find ourselves in split_nonconstant_init:
init = cp_fully_fold (init);
code = push_stmt_list ();
if (split_nonconstant_init_1 (dest, init))
where initially INIT was a CONSTRUCTOR, but cp_fully_fold returned
a TARGET_EXPR. This confuses split_nonconstant_i
OK.
On Thu, Mar 1, 2018 at 9:14 AM, Marek Polacek wrote:
> Here we were using pow2align as the right operand of <<. But for invalid
> alignments pow2align can be -1 which makes the shifting invalid. Fixed by
> moving the checking before using pow2align.
>
> Bootstrapped/regtested on x86_64-linu
On Wed, Feb 28, 2018 at 5:47 PM, Martin Sebor wrote:
> Attached is a patch for the failure to merge a subset of attributes
> specified on redeclarations of a function template with those of
> the first declaration (const, malloc, pure, noinline, noreturn,
> and nothrow). This was uncovered this m
On Thu, Mar 1, 2018 at 2:12 PM, Marek Polacek wrote:
> In this testcase we find ourselves in split_nonconstant_init:
>
>init = cp_fully_fold (init);
>code = push_stmt_list ();
>if (split_nonconstant_init_1 (dest, init))
>
> where initially INIT was a CONSTRUCTOR, but cp_ful
On Thu, Mar 1, 2018 at 7:02 AM, Matthew Fortune wrote:
> Hi,
>
> It seems we have had a bug for some time that causes an ICE and prevents the
> MIPS16 library builds from completing but is likely unrelated to MIPS16.
> The problem is when we call target_reinit and library functions get created
> a
On Thu, Mar 1, 2018 at 11:00 AM, Jason Merrill wrote:
> On Thu, Mar 1, 2018 at 9:41 AM, Jason Merrill wrote:
>> On Wed, Feb 28, 2018 at 4:04 PM, Paolo Carlini
>> wrote:
>>> On 28/02/2018 20:20, Jason Merrill wrote:
Hmm, the test seems wrong; the diagnostic talks about specializing the
This patch to the Go frontend by Than McIntosh avoids a compiler crash
on an invalid self-referential type. The compiler was crashing
partway through emitting an error for a bad self-referential struct
type (which refers to one of its own fields via an unsafe.Offset
expression). The patch tweaks
Richard Sandiford wrote:
> But there's the third question of whether the frame pointer is available
> for general allocation. By removing frame_pointer_required, we're saying
> that the frame pointer is always available for general use.
Unlike on ARM/Thumb-2, the frame pointer is unfortunately
Hi Steve,
2018-02-26 Steven G. Kargl
PF fortran/51434
* simplify.c (gfc_simplify_transfer): Reduce mold.
I think this should be "Resolve" (at least that is what your
patch shows).
OK for trunk, thanks for the patch!
Regards
Thomas
On Thu, Mar 01, 2018 at 08:10:03PM +0100, Jakub Jelinek wrote:
> On Thu, Mar 01, 2018 at 03:47:19PM -0300, Tulio Magno Quites Machado Filho
> wrote:
> > In order to use the __float128 in C++ it's necessary to check if
> > it is supported in libstdc++ (i.e. via _GLIBCXX_USE_FLOAT128) and if the
> >
On Thu, 1 Mar 2018, Jakub Jelinek wrote:
Note ia64, pa and powerpcspe likely need to be fixed too to predefine
__SIZEOF_FLOAT128__=16 if they provide __float128.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56540
(it only mentions ia64)
--
Marc Glisse
On Thu, Mar 01, 2018 at 09:44:57PM +0100, Thomas Koenig wrote:
> Hi Steve,
>
> > 2018-02-26 Steven G. Kargl
> >
> > PF fortran/51434
> > * simplify.c (gfc_simplify_transfer): Reduce mold.
>
> I think this should be "Resolve" (at least that is what your
> patch shows).
>
> OK for trun
On 02/27/2018 06:50 PM, Jeff Law wrote:
On 02/26/2018 05:47 PM, Martin Sebor wrote:
On 02/26/2018 12:13 PM, Jeff Law wrote:
On 02/24/2018 05:11 PM, Martin Sebor wrote:
Attached is an updated patch with a fix for a bad assumption
exposed by building the linux kernel.
On 02/19/2018 07:50 PM, Ma
Right now, I'm in the process of adding support for larger
vector_lengths in the nvptx BE. To reduce the size of the final patch,
I've separated all of the misc. function and variable renaming into this
patch. Once the nvptx BE is extended to support multiple CUDA
warps-sized vector lengths, in cer
From: Palmer Dabbelt
RISC-V relies on aggressive linker relaxation to get good code size. As
a result no text symbol addresses can be known until link time, which
means that alignment must be handled during the link. This alignment
pass is essentially just another linker relaxation, so this has
This crash was caused by unexpectedly seeing a USING_DECL. Normally we
want to make dependent using-decls visible to name lookup, so we know to
defer things to instantiation time. But here we're (a) explicitly
looking inside uninstantiated templates and (b) want to know the ctors
the template
On Thu, Mar 01, 2018 at 02:29:47PM -0500, Jason Merrill wrote:
> I think this should happen in the block with maybe_constant_value;
> cp_fold_rvalue doesn't do this.
This, then:
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2018-03-01 Marek Polacek
PR c++/84590
* cp-g
On Thu, Mar 01, 2018 at 01:56:50PM -0500, Jason Merrill wrote:
> On Thu, Mar 1, 2018 at 8:17 AM, Marek Polacek wrote:
> > On Wed, Feb 28, 2018 at 04:50:39PM -0500, Jason Merrill wrote:
> >> On Wed, Feb 28, 2018 at 4:19 PM, Marek Polacek wrote:
> >> > On Wed, Feb 28, 2018 at 10:51:17AM -0500, Jaso
Ok.
On Mar 1, 2018 4:40 PM, "Marek Polacek" wrote:
> On Thu, Mar 01, 2018 at 01:56:50PM -0500, Jason Merrill wrote:
> > On Thu, Mar 1, 2018 at 8:17 AM, Marek Polacek
> wrote:
> > > On Wed, Feb 28, 2018 at 04:50:39PM -0500, Jason Merrill wrote:
> > >> On Wed, Feb 28, 2018 at 4:19 PM, Marek Polac
On 1 March 2018 at 18:54, Marc Glisse wrote:
> On Thu, 1 Mar 2018, Tulio Magno Quites Machado Filho wrote:
>
>> In order to use the __float128 in C++ it's necessary to check if
>> it is supported in libstdc++ (i.e. via _GLIBCXX_USE_FLOAT128) and if the
>> compiler enabled its support too, e.g. -mfl
From: Bryan Drewery
FreeBSD has had this patch against Rust's bundled libbacktrace for a
while which allows not having /proc mounted to get the process name.
I am open to refactoring this if there's a better place to handle
some of this, such as configure.ac or a bsd-compat.c file.
Authored by:
Hi Carl,
On Thu, Mar 01, 2018 at 11:07:21AM -0800, Carl Love wrote:
> The following patch is a partial backport of mainline commit 257748 to
> remove the vec_vextract4b and vec_vinsert4b support. Note in GCC 7,
> vec_vextract4b is still used so only the external definitions,
> documentation and t
Hi!
Assertions are only useful when inline asm is not involved, otherwise users
can write anything they want.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2018-03-02 Jakub Jelinek
PR inline-asm/84625
* config/i386/i386.c (ix86_print_opera
Hi!
prev_real_insn doesn't skip over DEBUG_INSNs, on aarch64 on this
testcase we get both -fcompare-debug failure and wrong-code with -g.
Instead of adding yet another two:
do
insn = prev_real_insn (insn);
while (DEBUG_INSN_P (insn));
loops, this patch introduces new functions
Hi!
Eric has reported this testcase fails on sparc64 at -O0.
The reason is that after reporting the upcoming UB it actually performs the
UB, out of bounds write and still expects the test to finish properly, which
sometimes just isn't the case.
Fixed by making the ubsan runtime failure fatal and
While testing my recent changes to the handling of attributes
on C++ templates I noticed that the -finline-limit=N option
is not recognized in attribute or pragma optimize. In response
to the bug I raised, Richard you said the option is deprecated,
so I went ahead and documented the deprecation i
Hi Jakub,
On Fri, Mar 02, 2018 at 12:13:51AM +0100, Jakub Jelinek wrote:
> prev_real_insn doesn't skip over DEBUG_INSNs, on aarch64 on this
> testcase we get both -fcompare-debug failure and wrong-code with -g.
>
> Instead of adding yet another two:
> do
> insn = prev_real_insn (ins
Hi!
This patch fixes a couple of i18n bugs in gimple-ssa-sprintf.c.
One issue was incorrect format attribute for format_warning_at_substring,
which has ... and thus shouldn't use 0 for the last argument, but the first
non-named argument position.
Another one is that a couple of fmtwarn calls nee
On 03/01/2018 12:28 PM, Jason Merrill wrote:
On Wed, Feb 28, 2018 at 5:47 PM, Martin Sebor wrote:
Attached is a patch for the failure to merge a subset of attributes
specified on redeclarations of a function template with those of
the first declaration (const, malloc, pure, noinline, noreturn,
Ok.
On Mar 1, 2018 4:38 PM, "Marek Polacek" wrote:
> On Thu, Mar 01, 2018 at 02:29:47PM -0500, Jason Merrill wrote:
> > I think this should happen in the block with maybe_constant_value;
> > cp_fold_rvalue doesn't do this.
>
> This, then:
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
On 03/01/2018 04:25 PM, Jakub Jelinek wrote:
Hi!
This patch fixes a couple of i18n bugs in gimple-ssa-sprintf.c.
One issue was incorrect format attribute for format_warning_at_substring,
which has ... and thus shouldn't use 0 for the last argument, but the first
non-named argument position.
An
On Wed, Feb 28, 2018 at 09:59:27PM -0600, Peter Bergner wrote:
> >> So should we go with my original idea above? Or maybe we don't care
> >> that we XFAIL on some targets since we're just going to remove the
> >> test next release with the removal -maltivec=be?
> >
> > It would be nice to have cl
On Mar 1, 2018, Marek Polacek wrote:
> Here's my take on this; Alex, sorry for interfering.
No worries, thanks a lot for taking care of this!
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSF
On 3/1/18 7:45 PM, Segher Boessenkool wrote:
> On Wed, Feb 28, 2018 at 09:59:27PM -0600, Peter Bergner wrote:
>> PR target/84534
>> * gcc.target/powerpc/vec-setup-be-long.c: Add dg-xfail-run-if
>> on powerpc64le*-*-linux*.
>
> (wrong indent: should be a tab and no extra spaces).
On Mar 1, 2018, at 1:56 AM, Dominique d'Humières wrote:
>
>> Le 1 mars 2018 à 09:37, Richard Biener a écrit :
>>
>> In the PR Dominique says "With the patch the failures (-m32/-m64) went
>> down from 1059 to 467" which is a nice improvement. I'm not set up
>> to bootstrap on darwin but I expe
On Fri, Mar 2, 2018 at 12:10 AM, Jakub Jelinek wrote:
> Hi!
>
> Assertions are only useful when inline asm is not involved, otherwise users
> can write anything they want.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?
>
> 2018-03-02 Jakub Jelinek
>
>
On Fri, Mar 2, 2018 at 8:16 AM, Uros Bizjak wrote:
> On Fri, Mar 2, 2018 at 12:10 AM, Jakub Jelinek wrote:
>> Hi!
>>
>> Assertions are only useful when inline asm is not involved, otherwise users
>> can write anything they want.
IIRC, we can also handle { -1, -1, ... , -1 } in certain cases, but
On Fri, Mar 02, 2018 at 08:19:40AM +0100, Uros Bizjak wrote:
> On Fri, Mar 2, 2018 at 8:16 AM, Uros Bizjak wrote:
> > On Fri, Mar 2, 2018 at 12:10 AM, Jakub Jelinek wrote:
> >> Hi!
> >>
> >> Assertions are only useful when inline asm is not involved, otherwise users
> >> can write anything they w
Hi!
If we need to use thunks for ICF to functions with warning or error
attribute, their expansion will warn or error. This patch just punts
in those cases instead.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2018-03-02 Jakub Jelinek
PR ipa/84628
* i
On Fri, Mar 2, 2018 at 8:47 AM, Jakub Jelinek wrote:
> On Fri, Mar 02, 2018 at 08:19:40AM +0100, Uros Bizjak wrote:
>> On Fri, Mar 2, 2018 at 8:16 AM, Uros Bizjak wrote:
>> > On Fri, Mar 2, 2018 at 12:10 AM, Jakub Jelinek wrote:
>> >> Hi!
>> >>
>> >> Assertions are only useful when inline asm is
On Feb 28, 2018, Jason Merrill wrote:
> On Wed, Feb 28, 2018 at 7:08 AM, Alexandre Oliva wrote:
>> Don't allow the initializer expr to be NULL in a ctor initializer
>> list, make it error_marker_node instead.
> I don't want error_mark_nodes in a CONSTRUCTOR, either. When there
> isn't an NSDMI
On Feb 28, 2018, Jason Merrill wrote:
> On Wed, Feb 28, 2018 at 7:06 AM, Alexandre Oliva wrote:
>> We ICEd when returning a stmt expr that ends with an overloaded
>> function. It's ill-formed when we can't convert the function name to
>> the return type, but we should say that, not ICE.
> Hmm,
On Feb 28, 2018, Jason Merrill wrote:
> On Wed, Feb 28, 2018 at 12:24 AM, Alexandre Oliva wrote:
>> + if (processing_template_decl)
>> +result_type = cp_build_reference_type (result_type, !is_lvalue);
> If !is_lvalue, we don't want a reference type at all, as the result is
> a prvalue. is
Mark Wielaard is implementing support for LVU and IEPM in elfutils, and
he was surprised by the encoding of DW_AT_GNU_entry_view; so was I!
When GCC computes and outputs views internally (broken without internal
view resets), it outputs entry_view attributes as data: it knows the
view numbers. How
On Fri, 2 Mar 2018, Jakub Jelinek wrote:
> Hi!
>
> If we need to use thunks for ICF to functions with warning or error
> attribute, their expansion will warn or error. This patch just punts
> in those cases instead.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Looks
83 matches
Mail list logo
