Hi!
On the following testcase we ICE during error recovery.
Setting DECL_INITIAL of a FUNCTION_DECL to error_mark_node can't
be possibly helpful, the error must have been diagnosed already;
DECL_INITIAL on the FUNCTION_DECL should be kept as BLOCK.
Bootstrapped/regtested on x86_64-linux and i686-
Hi!
On various targets, %s in fprintf can't handle NULL arguments,
and even when edge->call_stmt is non-NULL, it still might have
UNKNOWN_LOCATION or BUILTINS_LOCATION, which have NULL filename.
In this particular case it is a fnsplit created call.
Fixed thusly, bootstrapped/regtested on x86_64-l
On Mon, Jan 26, 2015 at 10:10:56PM +0100, Jakub Jelinek wrote:
> Hi!
>
> On the following testcase we ICE, because we end up with a CALL_EXPR
> with error_mark_node argument and gimplification can't cope with that.
>
> Normally, if one or more arguments are error_mark_node we return -1
> and drop
Hi!
On x86_64-darwin, we ICE on one of the pr64307.c testcase, because
expand_thunk doesn't load non-gimple_val arguments into registers
for the first argument, only for all the other ones.
Supposedly normally thunks were meant to have this argument as pointer first
and thus it wasn't an issue, bu
> Hi!
>
> On various targets, %s in fprintf can't handle NULL arguments,
> and even when edge->call_stmt is non-NULL, it still might have
> UNKNOWN_LOCATION or BUILTINS_LOCATION, which have NULL filename.
> In this particular case it is a fnsplit created call.
>
> Fixed thusly, bootstrapped/regte
Hi!
On the following testcase we generate wrong code, because
apparently divmod_internal_2 relies on 0 being the topmost
element (at b_dividend[m]):
algorithm. M is the number of significant elements of U however
there needs to be at least one extra element of B_DIVIDEND
allocated, N is
Hi
Thanks a lot for those explanations, very educative. I was indeed
wondering what was the additional template parameter for.
So here is a new attempt. While moving __is_transparent to std
namespace I renamed to __has_is_transparent to not conflict with
existing __is_transparent. I
Hi!
If #pragma omp declare simd function has a name set using __asm,
DECL_ASSEMBLER_NAME starts with *. We certainly don't want to put
that * as part of the mangled name, if not anything else because
most of the assemblers don't handle it as part of identifiers.
Fixed thusly, committed to trunk
Hi Janus,
The testcase has a dependence on libubsan.so, which my LD_LIBRARY_PATH
does not seem to be able to resolve. It therefore fails in the
regression test. When I point to ~/lib64, I get the message:
/svn/trunk/gcc/testsuite/gfortran.dg/class_allocate_18.f90:8: runtime
error: signed integer
On 01/22/15 13:50, Chen Gang S wrote:
On 01/23/2015 03:53 AM, Jeff Law wrote:
On 01/22/15 12:42, Chen Gang S wrote:
Thank you very much for your help applying the 3 patches. :-)
No problem.
After finish the assignment working flow, I guess, I may have the write
access, then can finish the
On 01/26/15 09:45, Ilya Enkovich wrote:
Hi,
Currently chkp_call_returns_bounds_p works incorrectly for bounds narrowing.
Also it doesn't reflect recent changes in calls instrumentation. This patch
fixes the problem.
Bootstrapped and checked on x86_64-unknown-linux-gnu. OK for trunk?
Thank
Dear All,
The fix for the failing testcases in comments #6 and #7 in this PR
have been fixed as 'obvious' in r220140.
Thanks to Mikael for reopening the PR as a placeholder.
This is such an embarrassing bug that I intend to commit to 4.9 as
well even if it is not a regression, unless there are o
On 01/26/15 14:13, Jakub Jelinek wrote:
Hi!
On the following testcase we ICE during error recovery.
Setting DECL_INITIAL of a FUNCTION_DECL to error_mark_node can't
be possibly helpful, the error must have been diagnosed already;
DECL_INITIAL on the FUNCTION_DECL should be kept as BLOCK.
Bootst
On 01/26/15 07:30, Tobias Burnus wrote:
Matthias Klose wrote:
However for the libbacktrace and the libsanitizer builds, the AM_ENABLE_MULTILIB
macro is included way too late. Scan the generated configure file for
"cross_compiling" and see that the above snippet is added after the failing
checks
On 01/23/15 13:06, David Malcolm wrote:
libgccjit can print detailed logs and generate testcases for
reproducing bugs (using gcc_jit_context_set_logfile and
gcc_jit_context_dump_reproducer_to_file respectively).
It strikes me that such files really ought to contain version
information, so the fo
Hi Paul,
> The testcase has a dependence on libubsan.so, which my LD_LIBRARY_PATH
> does not seem to be able to resolve. It therefore fails in the
> regression test. When I point to ~/lib64, I get the message:
>
> /svn/trunk/gcc/testsuite/gfortran.dg/class_allocate_18.f90:8: runtime
> error: signe
On 01/26/15 09:42, David Malcolm wrote:
update_web_docs_svn-support-the-JIT-documention-v2.patch
From 7f7e15881981228e51b347f23df6e3106ddd68ea Mon Sep 17 00:00:00 2001
From: David Malcolm
Date: Fri, 23 Jan 2015 17:26:57 -0500
Subject: [PATCH] update_web_docs_svn: support the JIT documentation
On 1/27/15 05:56, Jeff Law wrote:
> On 01/22/15 13:50, Chen Gang S wrote:
>> On 01/23/2015 03:53 AM, Jeff Law wrote:
>>> On 01/22/15 12:42, Chen Gang S wrote:
Thank you very much for your help applying the 3 patches. :-)
>>> No problem.
>>>
After finish the assignment worki
> OK to apply ?
Ok.
> OK to apply ?
Ok.
On Fri, Jan 16, 2015 at 7:05 AM, Jeff Law wrote:
> On 01/15/15 16:43, Nathaniel Smith wrote:
>>>
>>>
>>> Jakub, myself and management have discussed this issue extensively and
>>> those
>>> patches specifically. I'm painfully aware of how this affects the
>>> ability
>>> to utilize numerical pack
This should fix most of the FAILs seen on targets that use
--enable-clocale=generic
When I added numpunct_shim I think I got confused/scared by the
clocale=gnu version of numpunct::_M_initialize_numpunct() and decided
not to touch the _M_grouping member of the cache. Looking at it again
now, _M_g
This is an updated patch of the patch proposed by Joern
https://gcc.gnu.org/ml/gcc-patches/2013-04/msg01332.html
which replaces MD_REDIRECT_BRANCH of which SH is the last user
with TARGET_CAN_FOLLOW_JUMP.
--
2015-01-27 Joern Rennecke
Kaz Kojima
PR target/64761
*
This patch is to fix 2 issues found in dbr_schedule when trying to
fix PR target/64761. The first is relax_delay_slots removes
the jump insn in the insns like below:
(jump_insn/j 74 58 59 (set (pc) (label_ref:SI 29)) ...)
(barrier 59 74 105)
(note 105 59 29 NOTE_INSN_SWITCH_TEXT_SECTIONS)
(code_l
[i'd like to add Joern to CC list because this is based on his patch.]
Hi,
This patch series is to fix PR target/64761 which is formally a 4.9/5
regression. The fix is splitted into 3 pieces:
[PATCH 1/3] Replace MD_REDIRECT_BRANCH with TARGET_CAN_FOLLOW_JUMP
[PATCH 2/3] [SH] Add jump insn for -
This patch adds a new jump insn for the jump crossing between hot/cold
pertitions and reenables -freorder-blocks-and-partition on SH in
some cases.
--
PR target/64761
* config/sh/sh.c (sh_option_override): Don't change
-freorder-blocks-and-partition to -freorder-blocks even
On Thu, 2015-01-22 at 23:46 +0100, Oleg Endo wrote:
> I will install this the patch from
> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01743.html
> in 24h if there are no further objections.
>
The above mentioned patch has been committed as r220081. This is a
small follow up patch that fixes
gcc_jit_context_get_last_error was documented as returning a string that's
valid for the rest of the lifetime of the context. In fact, the buffer
becomes invalid if any other errors occur on the context.
Fix the docs and header file comments to reflect this.
Also, fix a couple of other minor jit
On Mon, 2015-01-26 at 15:21 -0700, Jeff Law wrote:
> On 01/26/15 09:42, David Malcolm wrote:
>
> > update_web_docs_svn-support-the-JIT-documention-v2.patch
> >
> >
> > From 7f7e15881981228e51b347f23df6e3106ddd68ea Mon Sep 17 00:00:00 2001
> > From: David Malcolm
> > Date: Fri, 23 Jan 2015 17:26:5
On 01/20/2015 12:02 PM, H.J. Lu wrote:
On Tue, Jan 20, 2015 at 10:51 AM, Eric Botcazou wrote:
Ping? Any thoughts?
x86 for the family and x86-32/x86-64 for the 2 architectures?
Works for me.
[redirecting from gcc@ to gcc-patches@]
OK, here is a patch that attempts to implement that conv
Segher: I know you're not officially noted as a maintainer or reviewer
for combine.c, but that's something I'd like to change if you're
interested in a larger role. In the mean time, any feedback you have
would be appreciated.
So the issue mentioned in the BZ is that fairly obvious code sequ
> -Original Message-
> From: Segher Boessenkool [mailto:seg...@kernel.crashing.org]
> Sent: Tuesday, January 27, 2015 3:07 AM
> To: Hale Wang
> Cc: GCC Patches
> Subject: Re: [PATCH] [gcc, combine] PR46164: Don't combine the insns if a
> volatile register is contained.
>
> On Mon, Jan 26,
See $subj. Committed.
* config/rl78/rl78.c (move_elim_pass): Don't optimize away
volatile memory references.
Index: config/rl78/rl78.c
===
--- config/rl78/rl78.c (revision 220150)
+++ config/rl78/rl78.c (working c
> +/* Workaround -Wstrict-overflow false positive during profiledbootstrap. */
> +
> +# if GCC_VERSION >= 4004
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wstrict-overflow"
> +#endif
> +
#pragma diagnostic ignored was added in 4.4 but #pragma diagnostic
push/pop wasn't add
Gerald,
Could I get a hand on checking in this last addition?
-m 'Add a blurb to htdocs/gcc-5/changes.html to explain the
__has_cpp_attribute and
the equivalent __has_attribute macros.'
Thanks,
Ed
Sorry, I forgot to add gcc-patches.
Index: htdocs/gcc-5/changes.html
On Tue, Jan 27, 2015 at 11:49:55AM +0800, Hale Wang wrote:
Hi Hale,
> > > diff --git a/gcc/testsuite/gcc.target/arm/pr46164.c
> > > b/gcc/testsuite/gcc.target/arm/pr46164.c
> > > new file mode 100644
> > > index 000..ad3b7cb
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.target/arm/pr46164
On Mon, Jan 26, 2015 at 08:07:29PM -0700, Jeff Law wrote:
> The second change we need is an additional simplification.
>
> If we have
> (subreg:M1 (zero_extend:M2 (x))
>
> Where M1 > M2 and both are scalar integer modes. It's advantageous to
> strip the SUBREG and instead have a wider extension
Dear Janus,
I know somewhat less than nothing about such matters. I suggest that
you contact the authors of the testcases that use libubsan that you
mention.
Sorry
Paul
On 26 January 2015 at 22:20, Janus Weil wrote:
> Hi Paul,
>
>> The testcase has a dependence on libubsan.so, which my LD_LIBR
> From: Richard Earnshaw
> Sent: Wednesday, January 14, 2015 10:49 PM
>
> Sorry, not ok. These symbols pollute the global namespace, yet do not
> use reserved names.
Are you referring to the Lml_* symbols? They appear with local binding in
my environment which is expected since the single float
Ping?
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> Sent: Friday, January 23, 2015 4:23 PM
> To: Ramana Radhakrishnan
> Cc: gcc-patches
> Subject: RE: [PATCH, ARM] Fix PR64453: live high register not s
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
>
> >
> > Secondly, in a shared library environment you need to ensure that
> these
> > names remain private to the instance linked into the library, so that
> > you don't end up going t
> -Original Message-
> From: Segher Boessenkool [mailto:seg...@kernel.crashing.org]
> Sent: Tuesday, January 27, 2015 12:52 PM
> To: Hale Wang
> Cc: GCC Patches
> Subject: Re: [PATCH] [gcc, combine] PR46164: Don't combine the insns if a
> volatile register is contained.
>
> On Tue, Jan 2
Hi all,
As described in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64741 ,
ASan may currently report false positives for UBSan internal variables
due to their incomplete type information. This patch fixes this.
Bootstrapped and regtested on Linux x64. Ok to commit?
-Y
commit cf083510ece7b7
Updated patch below.
Jakub Jelinek wrote:
On Mon, Jan 26, 2015 at 01:14:39PM +0100, Tobias Burnus wrote:
The question is why I didn't see the nonsense in the test suite. It
doesn't seem to be tested for in gcc/testsuite/gfortran.dg/; it might be
tested in libgomp/testsuite/ - I don't recall whe
101 - 144 of 144 matches
Mail list logo
