From: Trevor Saunders
Hi,
just $subject
bootstrapped + regtested on x86_64-unknown-linux-gnu, ok?
Trev
gcc/
* graphite-htab.h: Use hash_map instead of hash_table.
* graphite-clast-to-gimple.c: Adjust.
* passes.c: Use hash_map instead of hash_table.
* sese.c: Li
On 07/04/2014 01:40 AM, Thomas Schwinge wrote:
> On Wed, 02 Jul 2014 14:53:19 +0200, I wrote:
>> I understand the attached fixed.f to be well-formed fixed-form Fortran
>> code, but it fails to parse in OpenACC mode:
>
> The legacy of Fortran ;-) strikes again:
>
> $ gcc/xgcc -Bgcc/ -Bx86_64-
Hello All,
This is related to the following bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102
I have tried to fix the e500v2 build on GCC v4.9.0 with the attached patch.
Can you please review and comment on the changes especially DWARF_FRAME_REGNUM,
DWARF_REG_TO_UNWIND_COLUMN definitions?
From: Trevor Saunders
Hi,
I'll admitt I'm not actually sure if the spec requires this, or if gcc 4.5 was
too picky, but this fixes the build with gcc 4.5, and it doesn't really hurt
anything.
bootstrapped + regtested on x86_64-unknown-linux-gnu with no regressions, ok?
Trev
gcc/
PR b
Ping? If nobody has anything else to say, I'm going to assume that such
a change is unobjectionable, and should not be listed in the ChangeLog.
Samuel Bronson writes:
> Ouch; it looks like my last attempt to reply to this missed gdb-patches@
> due to a gmane accident?
>
> Samuel Bronson writes
Hi,
I had to revert change to ipa-prop.c that made stmt_may_be_vtbl_ptr_store
to know that clobbers can not be such stores.
This triggered byg in detect_type_change_from_memory_writes. This function does
two things. First is that it tries to prove that vtbl pointer was not modified
in the function
> > Index: stor-layout.c
> > ===
> > --- stor-layout.c (revision 212098)
> > +++ stor-layout.c (working copy)
> > @@ -2065,7 +2065,7 @@ void
> > finish_builtin_struct (tree type, const char *name, tree fields,
> >
A couple of us noticed, over time, that our instructions on who
can sponsor SVN write access and how to get it are not as clear
as they could be. This tries to improve that.
And the text even is a bit shorter, overall.
Applied.
Gerald
Index: svnwrite.html
==
> Hi,
>
>I have attached a patch for this bug:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61599. Is this alright?
>
> Thanks
> Sri
> Patch to fix PR 61599:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61599
>
> Function int_size_in_bytes returns -1 in as the size in cases where
> the
Hi,
I have attached a patch for this bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61599. Is this alright?
Thanks
Sri
Patch to fix PR 61599:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61599
Function int_size_in_bytes returns -1 in as the size in cases where
the size of the type can var
On 07/07/14 15:22, Teresa Johnson wrote:
Ping. Jeff, any update on when you can look at this?
Hoping to do so on that long plane ride to the UK for Cauldron :-)
SLC->LAX->Heathrow Lots of uninterrupted time to look at those changes.
Jeff
Ping. Jeff, any update on when you can look at this?
Thanks,
Teresa
On Tue, May 27, 2014 at 7:10 AM, Teresa Johnson wrote:
> On Thu, Apr 17, 2014 at 6:23 AM, Teresa Johnson wrote:
>> On Wed, Apr 16, 2014 at 10:39 PM, Jeff Law wrote:
>>> On 03/26/14 17:44, Teresa Johnson wrote:
Recentl
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
> 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
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
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
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,
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 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
> >
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 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
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:
>>
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
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
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
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/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
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/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
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/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
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 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 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.
> >
Dear Paul,
> OK for trunk.
Thanks for the review. Committed as r212330.
Dominique
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
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
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, 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
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 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 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 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 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 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 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: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/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, 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
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
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.
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
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 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
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 condition that your commit the right patch :-), OK for 4.9.1
Indeed! Committed as r212329.
Thanks for the review.
Dominique
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): .
>
> 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
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
> 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
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
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
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
> 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:
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
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
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 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
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
As ARC maintainer, I have applied the appended patch to changes.html.
tmp
Description: Binary data
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
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
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 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
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 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
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 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
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 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
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 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
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:
> [.
> 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
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
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 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
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 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,
> 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 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
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 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
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 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 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
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
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
> 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
1 - 100 of 112 matches
Mail list logo
