Dear All,
This PR is caused by a rather unfortunate cast for the pointer to the
return value from matmul:
struct array1_real(kind=4) D.2357;
D.2357 = *(struct array1_real(kind=4) *) __result;
D.2357.data = 0B;
snip
_gfortran_matmul_r4 (*(struct array1_real(kind=4)
GI_raise (sig=)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:67
#2 0x20435ab0 in *__GI_abort () at abort.c:92
#3 0x49e0 in C::m_virt (this=0x4760 )
at /usr/local/gcc/gcc-20140707/gcc/testsuite/g++.dg/ipa/pr61085.C:26
#4 0x4760 in m_foo (this=0x60
Ping.
The patch is at [1].
[1] https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02430.html
Thanks,
Uros.
On Mon, Jun 30, 2014 at 9:59 PM, Uros Bizjak wrote:
> Hello!
>
> After fixing _.barriers and _.eh_range passes w.r.t. CALL_ARG_LOCATION
> notes, we can finaly move handling of trap shadows (PR
On Sun, 29 Jun 2014, Gerald Pfeifer wrote:
> On Thu, 12 Jun 2014, Richard Biener wrote:
> > It seems the https transition broke refering to permanently moved
> > URL gcc-3.0/gcc-3.0.html (I get a certificate error or some such),
> > breaking gennews and thus gcc_release. Fixed like below which
>
Jan Hubicka writes:
> Index: testsuite/g++.dg/ipa/imm-devirt-2.C
> ===
> --- testsuite/g++.dg/ipa/imm-devirt-2.C (revision 212278)
> +++ testsuite/g++.dg/ipa/imm-devirt-2.C (working copy)
> @@ -1,7 +1,7 @@
> /* Verify th
Paul Richard Thomas wrote:
> This PR is caused by a rather unfortunate cast for the pointer to the
> return value from matmul:
[...]
> The fix is obvious (ie use its natural kind)
[...]
> Dominique points out that the patch fixes PR58883 as well. I'll
> enhance the testcase appropriately.
Nice!
On Mon, Jul 07, 2014 at 04:52:39PM +1000, Kugan wrote:
Ok with following nit:
> +/* Checks if RTX of SUBREG_PROMOTED_VAR_P() is promoted for given SIGN. */
> +#define SUBREG_CHECK_PROMOTED_SIGN(RTX, SIGN)\
> +((SIGN) == SRP_POINTER ? SUBREG_PROMOTED_GET (RTX) == SRP_POINTER\
> + : (S
On Sun, 29 Jun 2014, Jan Hubicka wrote:
> > In addition of pr61644 and pr61646, this commit breaks a lot of
> > fortran tests with -flto -O0.
> Hello,
> the problem here is that we have POINTER_TYPE that points to array of variable
> length (not sure why it happens only with -O0). The ICE is intro
On Mon, 30 Jun 2014, Jan Hubicka wrote:
> >
> > Please revert the original patch instead which was not tested properly.
> > I'll get back to this after I return from vacation.
>
> OK, I will bootstrap and revert tomorrow morning.
>
> Note that testusite passes with the patch; the problem appea
On Mon, 30 Jun 2014, Dominique Dhumieres wrote:
> > Note that testusite passes with the patch; ...
>
> Confirmed. There is a typo
> s/fileds/fields/
>
> I have seen the failures because I now run the gfortran testsuite with
> the addition of '-g -flto'. Is it worth pushing in this direction?
Y
On Thu, 3 Jul 2014, Jakub Jelinek wrote:
> On Thu, Jul 03, 2014 at 09:41:15AM +0200, Richard Biener wrote:
> > On July 3, 2014 7:37:13 AM CEST, Jakub Jelinek wrote:
> > >On Wed, Jul 02, 2014 at 04:06:30PM -0700, Jason Merrill wrote:
> > >> I think that makes sense; I'm not aware of anyone working
Hi,
On 07/06/2014 08:20 PM, Tim Shen wrote:
I'd like to merge testcases to several huge files (char, wchar_t,
dg-do compile, locales, etc.) to (greatly) reduce duplicated
compilation.
We do not really care the fine-grained test report, do we? We hope
them all PASS.
Yes. As long as it's possib
> Furthermore, on 2014-05-12 I committed a patch changing libgfortran to
> be built with -std=gnu11 instead of -std=gnu99, so that we can make
> use of C11 functionality; see
> https://gcc.gnu.org/ml/fortran/2014-04/msg00101.html .
Committed as rev. 212323, thanks for the review.
I now propose th
FX writes:
>> Unfortunately, while the patch works fine on Solaris/x86, it broke
>> Solaris/SPARC bootstrap for trivial reasons: contrary to the ChangeLog,
>> configure and config.h.in weren't regenerated, thus FPSETSTICKY
>> wasn't defined.
>
> I apologize. Thanks for checking in the fix.
No wo
Hi Rainer,
> while the i386/amd64 values are the usual ones. Unfortunately,
> gcc/fortran/libgfortran.h hardcodes the more common values for
> GFC_FPE_*, and libgfortran/Makefile.am extracts them from there into
> fpu-target.inc. I'm unsure what's the best way to handle this.
No, we don’t hardc
On Sat, Jun 28, 2014 at 8:22 PM, Jan Hubicka wrote:
> Hi,
> This is first bug noticed by the type consistency checks I added.
>
> gcov_info_type is a structure that contains function pointer to itself. While
> building it we first build a structure w/o size and fields, then we build a
> function
On Sat, Jun 28, 2014 at 8:26 PM, Jan Hubicka wrote:
> Hi,
> this is another bug noticed. Here ipa-devirt attempts to merge binfos of two
> representations
> of the same ODR type, but forgets about variants.
>
> I also noticed that using variant instead of the type may end up in
> incomplete typ
On Sat, Jun 28, 2014 at 10:38 PM, Gerald Pfeifer wrote:
> Applied.
>
> Richi, Jakub, I noticed that you seem to have stopped including those
> with GCC 4.7 and later. Any particular reason? It appears useful to
> me.
Are you sure? I can still see them in 4.7 changes.html and newer
(but using h
On Sun, Jun 29, 2014 at 12:44 AM, Jan Hubicka wrote:
> Hi,
> this patch fixes another problem where we manage to produce a variant of
> variadic array that has different TYPE_SIZE (but an equivalent expression).
> This happens because remap_type_1 blindly copies all expressions referred by
> varia
Hi FX,
>> while the i386/amd64 values are the usual ones. Unfortunately,
>> gcc/fortran/libgfortran.h hardcodes the more common values for
>> GFC_FPE_*, and libgfortran/Makefile.am extracts them from there into
>> fpu-target.inc. I'm unsure what's the best way to handle this.
>
> No, we don’t ha
On Mon, Jun 30, 2014 at 1:38 AM, Marc Glisse wrote:
> Hello,
>
> with this patch on top of
> https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02315.html
> we finally warn for the testcase of PR 60517.
>
> The new function is copied from init_subtree_with_zero right above. I guess
> it might be possib
> FWIW, those FP_* values are also enum values in IRIX 6.5 , the
> only other SysV target I have around. Seems this file is common between
> all of them, so the risk should be manageable.
>
> The following patch does away with the #ifdef stuff and lets all
> gfortran.dg/ieee tests PASS on sparc-s
On Mon, Jun 30, 2014 at 8:56 AM, Jeff Law wrote:
>
> SSA_NAME_VALUE is, in effect, a chain of values. ie, it's possible for
> SSA_NAME_VALUE of any given SSA_NAME to refer to another SSA_NAME.
Hmm, but it shouldn't as we walk in dominator order and should
always do set_ssa_name_value (name,
FX writes:
>> FWIW, those FP_* values are also enum values in IRIX 6.5 , the
>> only other SysV target I have around. Seems this file is common between
>> all of them, so the risk should be manageable.
>>
>> The following patch does away with the #ifdef stuff and lets all
>> gfortran.dg/ieee te
On 04/07/14 17:24, Kyrill Tkachov wrote:
> Hi all,
>
> -mwords-little-endian was deprecated in GCC 4.7. This patch removes the
> option and associated machinery and documentation.
>
> Tested armeb-none-eabi and saw no regressions.
>
> Ok for trunk?
>
> Thanks,
> Kyrill
>
> 2014-07-04 Kyrylo
On Mon, Jun 30, 2014 at 5:54 PM, Richard Henderson wrote:
> On 06/29/2014 11:14 AM, Uros Bizjak wrote:
>>if (MEM_READONLY_P (x))
>> +if (GET_CODE (mem_addr) == AND)
>> + return 1;
>> return 0;
>
> Certainly missing braces here. But with that fixed the patch looks plausible.
> I
On Mon, Jul 7, 2014 at 11:29 AM, FX wrote:
>> Furthermore, on 2014-05-12 I committed a patch changing libgfortran to
>> be built with -std=gnu11 instead of -std=gnu99, so that we can make
>> use of C11 functionality; see
>> https://gcc.gnu.org/ml/fortran/2014-04/msg00101.html .
>
> Committed as re
> What about --disable-bootstrap? Does it just skip stage1 and stage2,
> and stage3 is used to compile libgfortran, or is the host compiler
> used to build libgfortran as well? If the former, yes I guess we can
> remove #ifnderf __GNUC__ stuff?
Even with --disable-bootstrap, libgfortran is compile
Dear Tobias,
The patch is so safe and, as you say, has no side effects that I will
commit to 4.9 first.
Cheers
Paul
On 7 July 2014 10:05, Tobias Burnus wrote:
> Paul Richard Thomas wrote:
>> This PR is caused by a rather unfortunate cast for the pointer to the
>> return value from matmul:
> [.
On 3 July 2014 10:34, Tom de Vries wrote:
> On 03-07-14 10:20, Marcus Shawcroft wrote:
>>
>> On 2 July 2014 09:02, Tom de Vries wrote:
>>>
>>> On 02-07-14 08:23, Marc Glisse wrote:
In the first example you gave, looking at the pattern (no match_dup,
setting the
full regis
On 7 July 2014 11:29, Christophe Lyon wrote:
> On 3 July 2014 10:34, Tom de Vries wrote:
>> On 03-07-14 10:20, Marcus Shawcroft wrote:
>>>
>>> On 2 July 2014 09:02, Tom de Vries wrote:
On 02-07-14 08:23, Marc Glisse wrote:
>
>
> In the first example you gave, looking at the
On Mon, 7 Jul 2014, Richard Biener wrote:
On Mon, Jun 30, 2014 at 1:38 AM, Marc Glisse wrote:
Hello,
with this patch on top of
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02315.html
we finally warn for the testcase of PR 60517.
The new function is copied from init_subtree_with_zero right a
Hi,
LOCALEDIR seams a build-time constant, which is an absolute path. But
* When releasing gcc binaries as a tarball, users can put it at any dir.
* For "Canadian" build, the dir layout on the build machine might be
different from the host machine.
For such cases, gcc most likely can not find th
Hi,
in April Andrew figured out that:
"The problem occurs in cp_parser_cast_expression. A term of having the
form (T())... cannot be parsed as a cast expression since the the
expansion is only applied to a part of the cast expression. If ...
follows the closing paren, the expression must be p
On Thu, Jul 3, 2014 at 1:08 AM, wrote:
> From: Trevor Saunders
>
> Hi,
>
> So apparently its not entirely obvious to everyone that removing the names of
> unused arguments is the best way of dealing with warnings about unused
> arguments in places like hooks where the argument is required for so
On Mon, Jul 7, 2014 at 11:45 AM, Richard Biene
wrote:
> On Thu, Jul 3, 2014 at 1:08 AM, wrote:
>> From: Trevor Saunders
>>
>> Hi,
>>
>> So apparently its not entirely obvious to everyone that removing the names of
>> unused arguments is the best way of dealing with warnings about unused
>> argu
On Thu, Jul 3, 2014 at 2:39 PM, Yuri Rumyantsev wrote:
> Ping!
Ok.
Thanks,
Richard.
> 2014-06-24 13:37 GMT+04:00 Yuri Rumyantsev :
>> Hi All,
>>
>> Here is a fix for PR 61576 - additional test was added that block
>> containing reduction statement is predecessor of block containing phi
>> to ch
Hi Cesar!
On Sun, 6 Jul 2014 16:10:56 -0700, Cesar Philippidis
wrote:
> This patch is the first step to enabling parallel reductions in openacc.
Thanks!
> As mentioned earlier, this patch isn't complete yet. For starters, parts
> of it depends on our internal ptx backend. I've temporarily rema
On Thu, Jul 3, 2014 at 11:53 AM, Mark Wielaard wrote:
> Hi,
>
> I pulled out the guality.exp [p]type test extension from the actual
> dwarf2out.c changes (which I will repost soon with some tweaks). I think
> the test extension itself is useful on its own (and will use it to
> add tests for my new
Janne Blomqvist wrote:
> On Mon, Jul 7, 2014 at 11:29 AM, FX wrote:
> > PS: I didnât touch libcaf, as I assume this might be compiled with a
> > different compiler. Am I right?
>
> My understanding is that libcaf is delivered in source form, and the
> end user is expected to compile it against th
On Mon, Jul 7, 2014 at 12:16 PM, FX wrote:
>> What about --disable-bootstrap? Does it just skip stage1 and stage2,
>> and stage3 is used to compile libgfortran, or is the host compiler
>> used to build libgfortran as well? If the former, yes I guess we can
>> remove #ifnderf __GNUC__ stuff?
>
> Ev
On Sun, Jul 6, 2014 at 4:23 PM, Marc Glisse wrote:
> On Mon, 30 Jun 2014, Jeff Law wrote:
>
>> On 06/28/14 16:33, Marc Glisse wrote:
>>>
>>> In an earlier version of the patch, I was using
>>> get_or_create_ssa_default_def (cfun, sym);
>>> (I was reusing the same variable). This passed bootstrap+t
As ARC maintainer, I have applied the appended patch to changes.html.
tmp
Description: Binary data
On Jul 5, 2014, at 11:42 AM, Gerald Pfeifer wrote:
> Farther below in wide-int.h, we define wide_int_storage as a class:
>
> class GTY(()) wide_int_storage
> {
> private:
>HOST_WIDE_INT val[WIDE_INT_MAX_ELTS];
>unsigned int len;
>unsigned int precision;
> :
>
> The patch below, w
Hi all,
This patch adds the rtx costs table for the Cortex-A5 core.
Tested arm-none-eabi and looked at the codegen for various codebases to
make sure there's no regression in code quality.
Ok for trunk?
Thanks,
Kyrill
2014-07-07 Kyrylo Tkachov
* config/arm/arm.c (cortexa5_extra_costs
Hi,
This change implements little-endian code generation for Signal
Processing Engine (SPE) operations.
Where possible changes are handled within the existing patterns with
suitable conditionals added to support the little-endian mode.
In some cases operand constraints are different between
Hi Ramana/Maxim,
On 18 June 2014 16:05, Venkataramanan Kumar
wrote:
> Hi Ramana,
>
> On 18 June 2014 15:29, Ramana Radhakrishnan wrote:
>> On Mon, Jun 16, 2014 at 1:53 PM, Venkataramanan Kumar
>> wrote:
>>> Hi Maintainers,
>>>
>>> This patch fixes the PR 60617 that occurs when we turn on reloa
In https://gcc.gnu.org/ml/fortran/2014-06/msg00150.html
I wrote
> I am now trying to do the back port to 4.9 and I got two failures: ...
Actually I did not applied the right patch, with it the testsuite pass without
regression. Still OK for 4.9.1?
TIA
Dominique
> Right, that's what I (vaguelly) remembered. Please consider a patch
> removing the ifndef __GNUC__ stuff from libgfortran.h pre-approved.
The only occurrence (outside of libcaf) is in libgfortran.h. Committed attached
patch as rev. 212328, after building on x86_64-linux.
FX
x
Description:
Dear Dominique,
On condition that your commit the right patch :-), OK for 4.9.1
Cheers
Paul
On 7 July 2014 13:48, Dominique Dhumieres wrote:
> In https://gcc.gnu.org/ml/fortran/2014-06/msg00150.html
> I wrote
>
>> I am now trying to do the back port to 4.9 and I got two failures: ...
>
> Actua
Dear Dominique,
OK for trunk.
Thanks for the patch
Paul
On 5 July 2014 18:09, Dominique Dhumieres wrote:
> On Mon, 05 May 2014, I have posted
> https://gcc.gnu.org/ml/fortran/2014-05/msg00012.html.
> On IRC Tobias Burnus remarked that the *.mod file in
> gfortran.dg/vect/fast-math-real8-pr4
On 07/07/2014 00:16, Mircea Namolaru wrote:
Hello,
In the isl library used by Graphite, isl_val replaced isl_val (that become
obsolete).
This patch implements the required changes in Graphite.
No regressions for c/c++/fortran on x86-64 Linux.
Hi Mircea,
the patch looks good and the directi
> On Sun, Jun 29, 2014 at 12:44 AM, Jan Hubicka wrote:
> > Hi,
> > this patch fixes another problem where we manage to produce a variant of
> > variadic array that has different TYPE_SIZE (but an equivalent expression).
> > This happens because remap_type_1 blindly copies all expressions referred
To quote William Shakespeare:
"FALSTAFF
‘Tis not due yet; I would be loath to pay him before
his day. What need I be so forward with him that
calls not on me? Well, ’tis no matter; honour pricks
me on. Yea, but how if honour prick me off when I
come on? how then? Can honour set to a leg? no: or
an
>
> Btw - this points to the "obvious" opportunity to make variant types
> a lot smaller (with the caveat to require an indirection to the main
> variant to access shared bits). That would also automagically
> help LTO streaming
Yeah, I was playing with this idea. Lets get things checked a
2014-07-07 Maciej W. Rozycki
gcc/
* config/rs6000/rs6000.c (output_vec_const_move): Handle
little-endian code generation.
* config/rs6000/spe.md (spe_evmergehi): Rename to...
(vec_perm00_v2si): ... this. Handle little-endian code
generation.
(spe_evmergehilo): Rename to...
(vec_perm01_v2si): .
> On condition that your commit the right patch :-), OK for 4.9.1
Indeed! Committed as r212329.
Thanks for the review.
Dominique
Hi,
This patch removes repeating strlen instrumentation.
Regtested/bootstrapped on x86_64-unknown-linux-gnu.
Ok to commit?
-Maxim
gcc/ChangeLog:
2014-06-24 Max Ostapenko
* asan.c (instrument_strlen_call): Do not instrument first byte in strlen
if already instrumented.
gcc/testsui
On Mon, Jul 07, 2014 at 06:09:41PM +0400, Maxim Ostapenko wrote:
> This patch removes repeating strlen instrumentation.
>
> Regtested/bootstrapped on x86_64-unknown-linux-gnu.
>
> Ok to commit?
Ok.
Jakub
This patch addresses an old issue of warning about macro touching string
literal even if the code is skipped:
#define BAZ "baz"
#if 0
"bar"BAZ
#endif
Just skip the warning Wliteral-suffix if the preprocessor is skipping.
Built and tested on x86_64-linux.
OK?
And for 4.9?
Thanks,
Ed Smith-R
On 07/07/2014 02:10 AM, Richard Biener wrote:
> On Mon, Jun 30, 2014 at 5:54 PM, Richard Henderson wrote:
>> On 06/29/2014 11:14 AM, Uros Bizjak wrote:
>>>if (MEM_READONLY_P (x))
>>> +if (GET_CODE (mem_addr) == AND)
>>> + return 1;
>>> return 0;
>>
>> Certainly missing braces her
When simplifying the points-to-set comparison I failed to realize
we don't expand ESCAPED special vars. The following does that
for the only interesting one (NONLOCAL).
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Will apply to trunk and 4.9 branch if that succeeds.
Richard.
The following fixes PR61680.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2014-07-07 Richard Biener
PR tree-optimization/61680
* tree-vect-data-refs.c (vect_analyze_data_ref_dependence):
Handle properly all read-write dependences with group acc
On Mon, 7 Jul 2014, David Edelsohn wrote:
> gcc/
> * config/rs6000/rs6000.c (output_vec_const_move): Handle
> little-endian code generation.
> * config/rs6000/spe.md (spe_evmergehi): Rename to...
> (vec_perm00_v2si): ... this. Handle little-endian code
> generation.
> (spe_evmergehilo): Rename to
On 07/07/2014 06:17 PM, Jakub Jelinek wrote:
On Mon, Jul 07, 2014 at 06:09:41PM +0400, Maxim Ostapenko wrote:
This patch removes repeating strlen instrumentation.
Regtested/bootstrapped on x86_64-unknown-linux-gnu.
Ok to commit?
Ok.
Jakub
Thanks, done in r212332.
-Maxim
On Mon, Jul 7, 2014 at 4:20 PM, Richard Henderson wrote:
> On 07/07/2014 02:10 AM, Richard Biener wrote:
>> On Mon, Jun 30, 2014 at 5:54 PM, Richard Henderson wrote:
>>> On 06/29/2014 11:14 AM, Uros Bizjak wrote:
if (MEM_READONLY_P (x))
+if (GET_CODE (mem_addr) == AND)
+
On 07/03/2014 02:53 AM, Evgeny Stupachenko wrote:
> -expand_vec_perm_palignr (struct expand_vec_perm_d *d)
> +expand_vec_perm_palignr (struct expand_vec_perm_d *d, int insn_num)
insn_num might as well be "bool avx2", since it's only ever set to two values.
> - /* Even with AVX, palignr only oper
On Mon, Jul 7, 2014 at 4:34 PM, Richard Biener
wrote:
> On Mon, Jul 7, 2014 at 4:20 PM, Richard Henderson wrote:
>> On 07/07/2014 02:10 AM, Richard Biener wrote:
>>> On Mon, Jun 30, 2014 at 5:54 PM, Richard Henderson wrote:
On 06/29/2014 11:14 AM, Uros Bizjak wrote:
>if (MEM_READONL
On 27 Jun 09:32, Bernd Schmidt wrote:
> Sorry for the delayed reply, I was travelling. There seem to be some
> thinkos in the configure script and Makefile; can you try the
> following (don't forget to regenerate configure)? It seems to work
> for ptx (with some additional changes to allow ptx buil
On 07/07/2014 07:34 AM, Richard Biener wrote:
> Ugh. I wasn't aware of that - is this documented anywhere? What
> exactly does such address conflict with? Does it inhibit type-based analysis?
Dunno if it's documented anywhere. Such addresses conflict with anything,
unless it can be proven not
On 07/07/2014 04:50 PM, Ilya Verbin wrote:
2) Or should I build accel compiler as a cross from
x86_64-pc-linux-gnu to x86_64-intelmic-linux-gnu?
Yes, that's the general idea.
Will it help to distinguish the libs?
Is libgomp the only problematic one? (Does the accel compiler even need
one?)
On Mon, Jul 7, 2014 at 10:33 AM, Maciej W. Rozycki
wrote:
>> Could you add a short comment explaining what the "0" and "1" labels
>> in vec_perm[01][01]_v2si mean?
>
> Like this?
>
> Maciej
>
> gcc-ppc-spe-le-update.diff
> Index: gcc-fsf-trunk-quilt/gcc/config/rs6000/spe.md
> =
On Mon, Jul 07, 2014 at 05:03:07PM +0200, Bernd Schmidt wrote:
> On 07/07/2014 04:50 PM, Ilya Verbin wrote:
> >2) Or should I build accel compiler as a cross from
> >x86_64-pc-linux-gnu to x86_64-intelmic-linux-gnu?
>
> Yes, that's the general idea.
>
> >Will it help to distinguish the libs?
>
>
On Mon, Jul 07, 2014 at 05:14:27PM +0200, Jakub Jelinek wrote:
> We need a libgomp for the offload targets to be different from the host
> libgomp even on targets like mic, because there are various omp_* functions
> that should behave differently. Or the host libgomp needs to have a way how
> to
Hi,
tested x86_64-linux, committed as obvious.
Thanks,
Paolo.
/cp
2014-07-07 Paolo Carlini
* class.c (check_for_override): Wrap the 'final' and 'override'
keywords in %< and %>.
/testsuite
2014-07-07 Paolo Carlini
* g++.dg/cpp0x/override1.C:
On Mon, 7 Jul 2014, David Edelsohn wrote:
> Yes, that's good. It helps if someone reading the code doesn't need to
> reverse engineer the numbering convention of the name.
Sure, I haven't questioned your request. Thanks for your review, applied
now.
Maciej
Dave,
> I guess if "\[ \t\]_*myBindC" worked on hppa*-*-linux*, then it would
> probably work on hpux and the target condition could be removed.
Does this mean that the following patch will succeed on hppa*-*-*
without/with -flto?
--- ../_clean/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
Dear Paul,
> OK for trunk.
Thanks for the review. Committed as r212330.
Dominique
On Fri, Jul 04, 2014 at 03:45:10PM +0100, Marcus Shawcroft wrote:
> On 24 June 2014 09:45, James Greenhalgh wrote:
>
> > 2014-06-20 James Greenhalgh
> >
> > * config/aarch64/aarch64-simd.md (move_lo_quad_internal_):
> > New.
> > (move_lo_quad_internal_be_): Likewise.
> >
On Mon, Jul 7, 2014 at 5:01 PM, Richard Henderson wrote:
> Early alpha can't store sub-4-byte quantities. Altivec can't store anything
> but 16 byte quantities. In order to perform smaller stores, we have to do a
> read-modify-write sequence on a larger aligned chunk of memory. Two such RMW
>
On 7/7/2014 12:13 PM, Dominique Dhumieres wrote:
Does this mean that the following patch will succeed on hppa*-*-*
without/with -flto?
--- ../_clean/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
2014-05-24 16:17:53.0 +0200
+++ gcc/testsuite/gfortran.dg/bind_c_array_params_2.
On 07/07/14 02:56, Richard Biener wrote:
On Mon, Jun 30, 2014 at 1:38 AM, Marc Glisse wrote:
Hello,
with this patch on top of
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02315.html
we finally warn for the testcase of PR 60517.
The new function is copied from init_subtree_with_zero right abo
I've changed the heading to "ARC" and put the item in its
proper alpha-sorted position to make it easier to find.
tmp
Description: Binary data
On 07/07/2014 09:35 AM, Uros Bizjak wrote:
> On Mon, Jul 7, 2014 at 5:01 PM, Richard Henderson wrote:
>
>> Early alpha can't store sub-4-byte quantities. Altivec can't store anything
>> but 16 byte quantities. In order to perform smaller stores, we have to do a
>> read-modify-write sequence on
Hello,
On 17/06/2014 19:41, Joseph S. Myers wrote:
> On Tue, 17 Jun 2014, Sylvestre Ledru wrote:
>
>> OK. I will do that.
>> We should test the following:
>> * default => run just -Wreturn-type
>> * -Wreturn-type => Run both
>> * -Wreturn-type + -Wmissing-return => Run both
>> * -Wno-return-type
On 07/06/14 08:23, Marc Glisse wrote:
What is the lifetime of an SSA_NAME with a default definition? The way
we handle it now, we start from the uses and go back to all blocks that
can reach one of the uses, since there is no defining statement where we
could stop
Right, that's exactly what I wou
On 07/03/14 04:18, Marek Polacek wrote:
On Mon, Jun 30, 2014 at 03:40:18PM -0700, Mike Stump wrote:
I glanced at it:
(gdb) p/x TYPE_ALIGN (type)
$1 = 2147483648
(gdb) p/x TYPE_ALIGN (type)
$2 = 0x8000
The callee is int, the caller uses unsigned int. The assert I see is because
the routin
On 07/04/14 03:05, Jan Hubicka wrote:
Hi,
BLOCK_SUPERCONTEXT for normal blocks leads all the way to FUNCTOIN_DECL. This
is not the case of some
automatically generated functions, like one for cilk. I think it is bug. This
patch fixes cilk, I will
look for other cases if that looks OK.
Bootst
Sri, can you provide examples to show why putting thunks into the same
section as the target function when function reorder is on can be bad
?
Thanks,
David
On Thu, Jun 26, 2014 at 10:29 AM, Sriraman Tallam wrote:
> Hi Honza,
>
>Could you review this patch when you find time?
>
> Thanks
> S
Hi,
in this bug submitter noticed that talking only about explicit
constructors without mentioning conversion operators is misleading in
C++11. Thus Jon suggested simply not mentioning the constructors in the
error message, which I find reasonable because after all it's about the
fact that th
Finally had some time to pick this up again. See responses and
questions below. But it looks like you are commenting on a stale
version of the patch. See the update I sent in March:
https://gcc.gnu.org/ml/gcc-patches/2014-03/msg01176.html
On Sun, May 25, 2014 at 10:43 PM, Jan Hubicka wrote:
>>
On July 7, 2014 11:32:10 AM CEST, Marc Glisse wrote:
>On Mon, 7 Jul 2014, Richard Biener wrote:
>
>> On Mon, Jun 30, 2014 at 1:38 AM, Marc Glisse
>wrote:
>>> Hello,
>>>
>>> with this patch on top of
>>> https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02315.html
>>> we finally warn for the testcase
Hello,
I apologize for taking so long to get into this patch. I ad busy time (wedding
and teaching), should be back in regular schedule now.
> Sri, can you provide examples to show why putting thunks into the same
> section as the target function when function reorder is on can be bad
> ?
C++ AB
On Mon, Jul 07, 2014 at 11:46:27AM +0200, Richard Biener wrote:
> On Mon, Jul 7, 2014 at 11:45 AM, Richard Biene
> wrote:
> > On Thu, Jul 3, 2014 at 1:08 AM, wrote:
> >> From: Trevor Saunders
> >>
> >> Hi,
> >>
> >> So apparently its not entirely obvious to everyone that removing the names
> >
On July 7, 2014 9:06:17 PM CEST, Trevor Saunders wrote:
>On Mon, Jul 07, 2014 at 11:46:27AM +0200, Richard Biener wrote:
>> On Mon, Jul 7, 2014 at 11:45 AM, Richard Biene
>> wrote:
>> > On Thu, Jul 3, 2014 at 1:08 AM, wrote:
>> >> From: Trevor Saunders
>> >>
>> >> Hi,
>> >>
>> >> So apparently
On Mon, Jul 07, 2014 at 09:28:55PM +0200, Richard Biener wrote:
> On July 7, 2014 9:06:17 PM CEST, Trevor Saunders
> wrote:
> >On Mon, Jul 07, 2014 at 11:46:27AM +0200, Richard Biener wrote:
> >> On Mon, Jul 7, 2014 at 11:45 AM, Richard Biene
> >> wrote:
> >> > On Thu, Jul 3, 2014 at 1:08 AM,
Hi,
enabling local aliases on AIX causes few ICEs. This is because localias
function looks
for existing alias. C++ FE produces those for thunk code but doesn't make them
correctly,
so we end up with missing DECL_CONTEXT that later confuses ipa-devirt.
This patch adds sanity checking of the alias
Hi,
AIX as' .set pseudoop has somewhat unexpected behaviour. It seems to be
implemented by syntactically replacin all appereances of the alias by
its target (that can be an expressoin) but it is still possible to globalize
the alias by .globl operation.
This breaks the assumption we make about al
> On 07/04/14 03:05, Jan Hubicka wrote:
> >Hi,
> >BLOCK_SUPERCONTEXT for normal blocks leads all the way to FUNCTOIN_DECL.
> >This is not the case of some
> >automatically generated functions, like one for cilk. I think it is bug.
> >This patch fixes cilk, I will
> >look for other cases if that
On Mon, 7 Jul 2014, Richard Biener wrote:
The main idea of these patches is that when we read from a place that
was clobbered, instead of dropping the clobber and reading what was
there before, we can use a variable with a default definition to mark
that the content is undefined. This enables
1 - 100 of 112 matches
Mail list logo
