On 07/27/13 01:09, Jason Merrill wrote:
On 07/26/2013 11:46 AM, Aldy Hernandez wrote:
How's this?
What branch is this supposed to apply to?
trunk, but it depends on the OMP_SIMD patch which is also awaiting
review (actually, just the vectorizer bits since Jakub wrote and can
pre-approve t
Hi Janus,
Janus Weil wrote:
here is a fix for class pointer initialization.
I think the patch looks reasonable. However, as soon as I try to use the
variable, I get an ICE in write_global_declarations -> symtab_get_node.
It works if one moves the targets into a module.
I wonder whether the
Hi Janus,
Janus Weil wrote:
OK for the trunk?
yes, the patch looks basically ok to me. Just one thing I did not
quite understand:
+ /* It can happen that the LHS has BT_DERIVED but it is in reality
+ a polymorphic variable. */
How exactly can it happen that a polymorphic variable i
Hi,
>>> OK for the trunk?
>>
>> yes, the patch looks basically ok to me. Just one thing I did not
>> quite understand:
>>
>> + /* It can happen that the LHS has BT_DERIVED but it is in reality
>> + a polymorphic variable. */
>>
>> How exactly can it happen that a polymorphic variable is
Committed.
On Fri, Jul 26, 2013 at 10:27 PM, Gabriel Dos Reis wrote:
> Andrew Sutton writes:
>
> | Fixed and committed, but I have a small follow-up related to parameter
> | packs in requires clauses. The checking for unexpanded parameter packs
> | treats the parameter declarations like regular
Passing the same argument to nonpointer dummy arguments is only
permitted if one does not modify the values.
gfortran was warning for intent(in)/intent(out) and for OUT/IN but not
for OUT/OUT. This patch now also warns for the latter.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Hi Tobias,
Passing the same argument to nonpointer dummy arguments is only
permitted if one does not modify the values.
gfortran was warning for intent(in)/intent(out) and for OUT/IN but not
for OUT/OUT. This patch now also warns for the latter.
Build and regtested on x86-64-gnu-linux.
OK for
Tobias Burnus wrote:
Janus Weil wrote:
yes, the patch looks basically ok to me. Just one thing I did not
quite understand:
+ /* It can happen that the LHS has BT_DERIVED but it is in reality
+ a polymorphic variable. */
How exactly can it happen that a polymorphic variable is BT_DERI
Hi,
On Fri, 2013-07-26 at 08:51 +0200, Uros Bizjak wrote:
> BTW: I am not c++ expert, but doesn't c++ offer some sort of
> abstraction to get rid of
>
> + union {
> +rtx (*argc0) (void);
> +rtx (*argc1) (rtx);
> +rtx (*argc2) (rtx, rtx);
> +rtx (*argc3) (rtx, rtx, rtx);
> +r
On Sat, 2013-07-27 at 14:52 +0200, Oleg Endo wrote:
> * I had to extend the number of max. args to 16, otherwise the SH
> backend's sync.md code wouldn't compile.
The error message was misleading. It wasn't sync.md but some other SH
insn gen func that takes 16 args. Anyway, doesn't change the o
Hi all,
I have just committed an obvious minus-two-line patch to re-enable an
error message for CLASS arrays (after a successful regtest):
http://gcc.gnu.org/viewcvs?rev=201284&root=gcc&view=rev
Cheers,
Janus
Andrew Sutton writes:
| Committed.
Merge from trunk as of revision 201285.
We will have to watch out for Tom's Makefile rewrite work.
-- Gaby
Tobias Burnus wrote:
Tobias Burnus wrote:
Janus Weil wrote:
yes, the patch looks basically ok to me. Just one thing I did not
quite understand:
+ /* It can happen that the LHS has BT_DERIVED but it is in
reality
+ a polymorphic variable. */
How exactly can it happen that a polymor
"Maciej W. Rozycki" writes:
> 2013-07-26 Maciej W. Rozycki
>
> gcc/
> * config/mips/linux.h (GLIBC_DYNAMIC_LINKER): Handle `-mnan=2008'.
> (UCLIBC_DYNAMIC_LINKER): New macro.
> * config/mips/linux64.h (GLIBC_DYNAMIC_LINKER32): Handle
> `-mnan=2008'.
> (GLIBC
On 26 July 2013 17:04:41 David Malcolm wrote:
diff --git a/gcc/passes.c b/gcc/passes.c
index ce5cdeb..dd1b0ba 100644
--- a/gcc/passes.c
+++ b/gcc/passes.c
+
+void gt_pch_nx_pipeline (void *this_obj, void *p,
+gt_pointer_operator op, void *cookie)
+{
+ pipeline *pass
2013-07-27 Joern Rennecke
* config/epiphany/epiphany.c (epiphany_compute_frame_size):
Also reserve space for saving UNKNOWN_REGNUM for leaf functions.
Index: config/epiphany/epiphany.c
===
--- config/epiphany/epi
Tobias Burnus wrote:
Giving up on the class.c version, would be the following change okay?
+ if (expr1->ts.type == BT_DERIVED && expr2->ts.type == BT_CLASS
+ && expr2->expr_type != EXPR_FUNCTION)
+{
+ gfc_add_data_component (expr2);
+ /* The following is required as gfc_add_d
> "Gaby" == Gabriel Dos Reis writes:
Gaby> We will have to watch out for Tom's Makefile rewrite work.
FWIW, I've found rebasing this series to be very easy.
Due to the way it is split up, only one patch (the big manual dependency
removal one) only ever has "hard" conflicts, and that patch is
PR57993 reports a scenario where a conditional candidate is incorrectly
replaced when its putative "hidden basis" (the basis hidden by one or
more PHI nodes) does not dominate all of the PHI nodes on which the
candidate depends.
This indicates that the hidden basis was incorrectly identified as a
Tom Tromey writes:
| > "Gaby" == Gabriel Dos Reis writes:
|
| Gaby> We will have to watch out for Tom's Makefile rewrite work.
|
| FWIW, I've found rebasing this series to be very easy.
| Due to the way it is split up, only one patch (the big manual dependency
| removal one) only ever has
Refractor the whole Thompson matcher using the queue-based(BFS)
Bellman-Ford algorithm. Fix the grouping problem.
The original implementation uses a stack, which possibly runs slower
when deduplicating; and cannot handle gourping correctly.
The patch may not be very clear, so here's the whole fil
Eric Botcazou writes:
> Index: gcc.dg/vect/pr57705.c
> ===
> --- gcc.dg/vect/pr57705.c (revision 201177)
> +++ gcc.dg/vect/pr57705.c (working copy)
> @@ -61,5 +61,6 @@ main ()
>return 0;
> }
>
> -/* { dg-final { scan-t
22 matches
Mail list logo
