[Bug debug/52160] gdb ignores line "bar: if(foo)goto bar;"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52160
Jan Kratochvil changed:
What|Removed |Added
CC||jan.kratochvil at redhat
||dot com
--- Comment #2 from Jan Kratochvil
2012-09-16 07:09:26 UTC ---
The same problem with IMO more minimal reproducer:
--
int i;
void f (void)
{
redo:
if (i)
goto redo;
}
int main (void)
{
f ();
return 0;
}
--
(gdb) break f
Breakpoint 1 at 0x4004c2: file 123.c, line 6.
(gdb) run
Starting program: /home/jkratoch/t/123
[Inferior 1 (process 308) exited normally]
--
f:
.LFB0:
.file 1 "123.c"
.loc 1 3 0
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
jmp .L2
.L4:
.loc 1 6 0
<-- GDB places breakpoint here
nop
.L2:
.loc 1 5 0
[Bug debug/52160] gdb ignores line "bar: if(foo)goto bar;"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52160 --- Comment #3 from Jan Kratochvil 2012-09-16 07:10:39 UTC --- FAIL: gcc (GCC) 4.4.7 FAIL: gcc (GCC) 4.5.4 FAIL: gcc (GCC) 4.6.4 20120916 (prerelease) FAIL: gcc (GCC) 4.7.2 20120916 (prerelease) FAIL: gcc (GCC) 4.8.0 20120916 (experimental)
[Bug fortran/54572] Use libbacktrace library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572 --- Comment #2 from Janne Blomqvist 2012-09-16 08:33:42 UTC --- (In reply to comment #1) > You need unwind frames present for this to work, i.e. the space (and to some > extent optimization-reducing - yes I'm sure) overhead of -funwind-tables. > (Only > x86_64 has this on, effectively.) How is this different from the current backtracing implementation in libgfortran? (That being said, we should probably modify the driver program to always add -funwind-tables, which IIRC isn't done today)
[Bug lto/54598] New: ICE: Segmentation fault in lto1 at tree-streamer-in.c:unpack_ts_fixed_cst_value_fields()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54598
Bug #: 54598
Summary: ICE: Segmentation fault in lto1 at
tree-streamer-in.c:unpack_ts_fixed_cst_value_fields()
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, lto
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
Target: avr
Created attachment 28199
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28199
lto1-const_fixed-ice.c: C test case
== C Test Case ==
_Fract zero_r (_Fract r)
{
if (r < 0r)
return 0r;
return r;
}
int main (void)
{
return 0;
}
== Command Line ==
$ avr-gcc lto1-const_fixed-ice.c -flto -v
There are also more complicated test cases in the gcc test suite that trigger
this ICE, cf. http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01020.html
== Configure ==
The following dump is from a build=i686-linux-gnu host=i386-mingw32 canadian
cross, but I also get the ICE with native x86-linux cross compiler, just omit
--host= and --build=.
Target: avr
Configured with: ../../gcc.gnu.org/trunk/configure --target=avr
--prefix=/local/gnu/install/gcc-4.8-mingw32 --host=i386-mingw32
--build=i686-linux-gnu --enable-languages=c,c++ --disable-nls --disable-shared
--with-dwarf2
Thread model: single
gcc version 4.8.0 20120915 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-flto' '-v'
GNU C (GCC) version 4.8.0 20120915 (experimental) (avr)
compiled by GNU C version 3.4.5 (mingw-vista special r2), GMP version
4.3.2, MPFR version 2.4.2, MPC version 0.8.2
COLLECT_GCC_OPTIONS='-c' '-v'
'-fltrans-output-list=c:\Temp\cc8RcTpj.ltrans.out' '-fltrans' '-o'
'c:\Temp\cc8RcTpj.ltrans0.ltrans.o'
e:/winavr/4.8_2012-09-15/lib/gcc/../../libexec/gcc/avr/4.8.0/lto1.exe -quiet
-dumpbase cc8RcTpj.ltrans0.o -auxbase-strip c:\Temp\cc8RcTpj.ltrans0.ltrans.o
-version -fltrans-output-list=c:\Temp\cc8RcTpj.ltrans.out -fltrans
@c:\Temp\ccIimPk0 -o c:\Temp\ccgryuvQ.s
GNU GIMPLE (GCC) version 4.8.0 20120915 (experimental) (avr)
compiled by GNU C version 3.4.5 (mingw-vista special r2), GMP version
4.3.2, MPFR version 2.4.2, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU GIMPLE (GCC) version 4.8.0 20120915 (experimental) (avr)
compiled by GNU C version 3.4.5 (mingw-vista special r2), GMP version
4.3.2, MPFR version 2.4.2, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
In function 'zero_r':
lto1.exe: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
lto-wrapper: e:/WinAVR/4.8_2012-09-15/bin/avr-gcc returned 1 exit status
e:/winavr/4.8_2012-09-15/bin/../lib/gcc/avr/4.8.0/../../../../avr/bin/ld.exe:
lto-wrapper failed
collect2.exe: error: ld returned 1 exit status
[Bug fortran/54597] Function can't return string without trailing spaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54597 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org 2012-09-16 08:45:09 UTC --- (In reply to comment #0) > I would like to write a function that will return string without trailing > spaces, the prototype of the function is as following: > > module mod > > contains > > function foo() > > character(*), allocatable :: foo > character(1000) bar > > bar = "abc" > foo = bar > > end function foo > > end module mod > > program main > > use mod > > write(*, *) , foo(), > > end program main > > The result of "gfortran" still contains trailing spaces, but "ifort" works as > expected. Is this the actually code you want to compile? laptop:kargl[207] gfortran -o z d.f90 d.f90:5.4: function foo() 1 Error: Character-valued module procedure 'foo' at (1) must not be\ assumed length
[Bug fortran/54597] Function can't return string without trailing spaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54597 --- Comment #2 from Li Dong 2012-09-16 08:52:00 UTC --- (In reply to comment #1) > (In reply to comment #0) > > I would like to write a function that will return string without trailing > > spaces, the prototype of the function is as following: > > > > module mod > > > > contains > > > > function foo() > > > > character(*), allocatable :: foo > > character(1000) bar > > > > bar = "abc" > > foo = bar > > > > end function foo > > > > end module mod > > > > program main > > > > use mod > > > > write(*, *) , foo(), > > > > end program main > > > > The result of "gfortran" still contains trailing spaces, but "ifort" works > > as > > expected. > > Is this the actually code you want to compile? > > laptop:kargl[207] gfortran -o z d.f90 > d.f90:5.4: > > function foo() > 1 > Error: Character-valued module procedure 'foo' at (1) must not be\ >assumed length Yes, it is. I am using gfortran 4.7.1.
[Bug c++/54596] seg fault building Eigen stuff with cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54596 --- Comment #1 from Mikael Pettersson 2012-09-16 09:03:14 UTC --- (In reply to comment #0) > The generated *.i* is attached. No it isn't. If it's very large you may have to compress it. Also, 4.5.3 is no longer supported, please try 4.6.3 or the 4.7.2 release candidate.
[Bug c++/54596] seg fault building Eigen stuff with cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54596 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-09-16 Ever Confirmed|0 |1
[Bug fortran/54599] New: Issues found in gfortran by the Coverity Scan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54599
Bug #: 54599
Summary: Issues found in gfortran by the Coverity Scan
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: tkoe...@gcc.gnu.org
The following bugs were found by http://scan.coverity.com/ for gcc/fortran. I
walked through the list and extracted the following issues.
dependency.c:LOGICAL BUG (unreachable code)
401 if (l == 0)
415 else
416{
417 if (l != 0)
I think one of the "l" should be "r".
dependency.c: check_data_pointer_types
Same line twice:
946 if ( expr1->expr_type != EXPR_VARIABLE
947|| expr1->expr_type != EXPR_VARIABLE)
interface.c: gfc_compare_derived_types BUG
Same line twice:
450 if ( !(dt1->ts.type == BT_DERIVED && derived1 ==
dt1->ts.u.derived)
451&& !(dt1->ts.type == BT_DERIVED && derived1 ==
dt1->ts.u.derived)
openmp.c: gfc_resolve_do_iterator
Dead code: Line 1705 is unreachable.
1690 for (j = 1; j < i; j++)
1702 if (j < i)
1703break;
1704 do_code2 = do_code2->block->next;
1705}
cpp.c: print_lineBUG
841 if (loc.sysp == 2)
843 else if (loc.sysp == 1)
Issue:
sysp is "bool".
interface.c:
CID 722306: Array compared against 0 (NO_EFFECT)
At (1): Comparing an array to null is not useful: "ref->u.ar.as->upper".
2266 else if (ref->type == REF_ARRAY && ref->u.ar.type == AR_FULL
2267 && ref->u.ar.as->lower && ref->u.ar.as->upper)
target-memory.c:
At (4): Assigning: unsigned variable "len" = "gfc_target_expr_size(gfc_expr
*)".
643 len = gfc_target_expr_size (e);
CID 722280: Argument cannot be negative (NEGATIVE_RETURNS)
At (5): "len" is passed to a parameter that cannot be negative.
Here, len = size_t (unsigned); should one use HOST_WIDE_INT + and gcc_assert?
error.c: Side effect in assertion
547 gcc_assert (*format++ == '$');
The containing function might work differently in a non-debug build.
resolve.c
Loop only executed once. Should break be continue?
7419 for (i = ar->dimen; i < ar->codimen + ar->dimen; i++)
7424 if (i == (ar->dimen + ar->codimen - 1))
7428 goto failure;
7429}
7430 break;
7433 if (ar->dimen_type[i] == DIMEN_STAR && i == (ar->dimen + ar->codimen
- 1)
7434 && ar->stride[i] == NULL)
7435break;
7439 goto failure;
7440}
interface.c: gfc_compare_derived_types
First, one checks whether "derived1" is NULL, then one uses
it unconditionally. Add an assert - and remove the check?
402 if (derived1 != NULL && derived2 != NULL
411 if (strcmp (derived1->name, derived2->name))
RFC: Should we address the following two warnings?
resolve.c:
Potential buffer overflow?
4015 strcpy (msg, _("COMPLEX quantities cannot be compared at %L"));
Recall, _(...) is gettext() and returns a string from the translator's .po
file; msg is 200 bytes large, i.e. 50 4-byte characters.
intrinsic.c: add_sym
Possible-buffer-overflow warning.
--- a/gcc/fortran/intrinsic.c
+++ b/gcc/fortran/intrinsic.c
@@ -273,2 +273,3 @@ add_sym (const char *name, gfc_isym_id id, enum klass cl,
int actual_ok, bt type
+ gcc_assert (strlen (name) + 10 < sizeof (buf));
strcpy (buf, "_gfortran_");
[Bug c++/54590] Incorrect multi-inheritence bases layout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54590
--- Comment #2 from Sun, Chaoyang 2012-09-16
11:38:24 UTC ---
(In reply to comment #1)
> The first word contains a pointer to the vtable for X.
If the first word is the vtable of X, the memory layout should be:
{
vptr of x;
data of B;
vptr of A;
}?
but the actual layout is:
{
vptr of X and A
data of B;
}
g++ swapped the memory ordered of A and B.
also,if I have
struct C{ virtual void foo() {} };
and X is defined:
struct X : public B, A,C { };
the actual layout will be:
{
vptr of X and A
data of B;
vptr of C;
}
Is it expected too? If so, it's too difficult to predicate the memory order of
each bases.
[Bug c++/54590] Incorrect multi-inheritence bases layout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54590 Sun, Chaoyang changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #3 from Sun, Chaoyang 2012-09-16 11:40:09 UTC --- Back to unconfirmed. Maybe it's a "feature"?
[Bug preprocessor/54600] New: Header file missing from dependency file.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54600 Bug #: 54600 Summary: Header file missing from dependency file. Classification: Unclassified Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassig...@gcc.gnu.org ReportedBy: mr.duncan.mo...@gmail.com In this simplified example, the local unistd.h is absent from the dependency file. % gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-cygwin/4.5.3/lto-wrapper.exe Target: i686-pc-cygwin Configured with: /gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3/configure --srcdir=/gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --datarootdir=/usr/share --docdir=/usr/share/doc/gcc4 -C --datadir=/usr/share --infodir=/usr/share/info --mandir=/usr/share/man -v --with-gmp=/usr --with-mpfr=/usr --enable-bootstrap --enable-version-specific-runtime-libs --libexecdir=/usr/lib --enable-static --enable-shared --enable-shared-libgcc --disable-__cxa_atexit --with-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions --enable-languages=ada,c,c++,fortran,java,lto,objc,obj-c++ --enable-graphite --enable-lto --enable-java-awt=gtk --disable-symvers --enable-libjava --program-suffix=-4 --enable-libgomp --enable-libssp --enable-libada --enable-threads=posix --with-arch=i686 --with-tune=generic --enable-libgcj-sublibs CC=gcc-4 CXX=g++-4 CC_FOR_TARGET=gcc-4 CXX_FOR_TARGET=g++-4 GNATMAKE_FOR_TARGET=gnatmake GNATBIND_FOR_TARGET=gnatbind --with-ecj-jar=/usr/share/java/ecj.jar Thread model: posix gcc version 4.5.3 (GCC) % cat xyz.c #include % cat fcntl.h #pragma GCC system_header #include % cat unistd.h dummy error line % gcc -E -MMD -I. -o xyz.i xyz.c The local unistd.h is included: % cat xyz.i # 1 "xyz.c" # 1 "" # 1 "" # 1 "xyz.c" # 1 "./fcntl.h" 1 # 2 "./fcntl.h" 3 # 1 "./unistd.h" 1 3 dummy error line # 2 "./fcntl.h" 2 3 # 1 "xyz.c" 2 , but not put in the dependency file: % cat xyz.d xyz.o: xyz.c fcntl.h I would expect: % cat xyz.d xyz.o: xyz.c fcntl.h unistd.h Note that replacing -MMD by -MD gives the expected dependency file.
[Bug fortran/54597] Function can't return string without trailing spaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54597 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-09-16 CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Tobias Burnus 2012-09-16 12:36:39 UTC --- I think your test case is wrong; I sincerely doubt that your test case matches what you have actually used. However, there is a bug which matches your description. This bug has been solved in GCC 4.8 but it does exist in GCC 4.7.x. (GCC 4.8 is the current developer version of GCC, see http://gcc.gnu.org/wiki/GFortranBinaries for information about how to build it yourself or where to obtain unofficial builds of it.) But back to your test case: function foo() character(*), allocatable :: foo The "*" is invalid in this context; it means that the length is assumed - but there is nothing from where it can be assumed. You have to use ":" (deferred length) instead of "*". Additionally, you need to use TRIM in bar = "abc" foo = TRIM(bar) In that case, the result is the expected "abc" (in GCC 4.8; as written, 4.7 has a bug). Without TRIM the correct result is "abc followed by 997 blanks and then the tailing ". (With GCC 4.7, the result with TRIM is - wrongly - the same as with TRIM.)
[Bug c++/54590] Incorrect multi-inheritence bases layout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54590 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||paolo.carlini at oracle dot ||com Resolution||INVALID --- Comment #4 from Paolo Carlini 2012-09-16 12:37:22 UTC --- When you say "should be", are you referring to the Itanium ABI? Because that is the reference, and unless you have solid evidence that we are misimplementing the ABI, this is not a Bug.
[Bug fortran/54597] Function can't return string without trailing spaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54597 --- Comment #4 from Li Dong 2012-09-16 12:58:03 UTC --- (In reply to comment #3) > But back to your test case: > > function foo() > character(*), allocatable :: foo > > The "*" is invalid in this context; it means that the length is assumed - but > there is nothing from where it can be assumed. You have to use ":" (deferred > length) instead of "*". Sorry, you are right! I have typed the wrong code, it should be "deferred-length allocatable character" as following: function foo() character(:), allocatable :: foo I have post in Intel Fortran forum as http://software.intel.com/en-us/forums/topic/326820.
[Bug c++/54601] New: AIX uses atexit which causes unloading of shared modules to break
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54601
Bug #: 54601
Summary: AIX uses atexit which causes unloading of shared
modules to break
Classification: Unclassified
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pedz...@gmail.com
Created attachment 28200
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28200
git diff -c of base 4.5.2 tarball against new files and changes
The bug was hit when using Apache httpd with a module called passenger.
passenger uses some c++ code. httpd does an unload of all of the modules that
it loads when it exits. The symptom is a core dump because by the time the
atexit is run, the TOC entries as well as the code to execute which are
registered as the DTORs have been unloaded.
Using the x1.cpp attached, I determined that the atexit is used to register a
DTOR for a static object with a non-trivial DTOR that is declared inside a
function. The DTOR is registered only if the function is called. (x1.cpp does
not demonstrate the problem. It was just used to educate me about when gcc
used the atexit service.)
I am also supplying a patch to the base 4.5.2 tarball that fixes the problem.
I stole the cxa_atexit and cxa_finialize from GNU's glibc-2.16.0
implementation. I believe I have removed glibc's locking and successfully
added back in the locking that gcc uses so that the file is built properly on
the four different platforms: 32 bit, 32 bit threaded, 64 bit and 64 bit
threaded.
The changes to the configure and makefiles will need to be ported to the real
files. I added references to the two new files introduced into the makefile
and changed the configure script to assume cxa_atexit is present on AIX systems
so that it will honor the --enable-__cxa_atexit configure option. The options
I used for configure are:
"--with-gmp=${PUBLIC_BASE}" \
"--with-mpfr=${PUBLIC_BASE}" \
"--with-mpc=${PUBLIC_BASE}" \
"--disable-nls" \
"--enable-threads=aix" \
"--with-libiconv-prefix=/usr" \
"--enable-__cxa_atexit" \
"--enable-languages=c,c++"
If all goes well, I propose to have --enable-__cxa_atexit be the default for
AIX.
The final big change is to collect2. The changes are rather large. I tried to
keep the proper style. There may be some debugging that can be removed. A new
c stub is created in the first link pass so that __dso_handle can be declared
to allow the first link to complete. I generalized a few things in the
process. I hope all that is ok.
I've used this new compiler for a month now but only on the original problem.
All seems to be working.
[Bug c++/54601] AIX uses atexit which causes unloading of shared modules to break
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54601 --- Comment #1 from Perry Smith 2012-09-16 14:39:05 UTC --- Created attachment 28201 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28201 Educational program demonstrating when atexit is used. Run it without an argument, the function that declares the static is not called -- thus the DTOR is not registered. Run it with an argument to call the function that declares the static.
[Bug c++/54601] AIX uses atexit which causes unloading of shared modules to break
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54601 --- Comment #2 from Perry Smith 2012-09-16 14:40:25 UTC --- Forgot to mention. A long thread discussing the issue, etc is here: http://www.mail-archive.com/gcc@gcc.gnu.org/msg65140.html
[Bug libobjc/51891] class_copyIvarList crashes on empty ivars
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51891 Dimitris Papavasiliou changed: What|Removed |Added CC||dpapavas at gmail dot com --- Comment #1 from Dimitris Papavasiliou 2012-09-16 15:21:04 UTC --- The runtime crashes at libobj.c/ivars.c line 191: count = ivar_list->ivar_count; The problem is that, when a class has no instance variables ivar_list will be NULL so this needs to be checked for.
[Bug target/54602] New: [SH] Register pop insn not put in rts delay slot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54602
Bug #: 54602
Summary: [SH] Register pop insn not put in rts delay slot
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
Target: sh*-*-*
The following case:
int test01 (int a, int b);
int test00 (int a, int b, int c, int d)
{
return test01 (a, b) + c;
}
Compiled with -O2 -m2:
mov.l.L3,r0 ! 9movsi_i/1[length = 2]
mov.l r8,@-r15! 26movsi_i/7[length = 2]
sts.l pr,@-r15! 27movsi_i/9[length = 2]
jsr @r0 ! 12call_valuei[length = 2]
mov r6,r8 ! 4movsi_i/2[length = 2]
add r8,r0 ! 14*addsi3_compact[length = 2]
lds.l @r15+,pr! 33*movsi_pop/3[length = 2]
mov.l @r15+,r8! 34*movsi_pop/1[length = 2]
rts
nop ! 36*return_i[length = 4]
Compiled with -O2 -m2a:
mov.l .L3,r0 ! 9movsi_ie/1[length = 2]
mov.l r8,@-r15! 30movsi_ie/9[length = 4]
sts.l pr,@-r15! 31movsi_ie/11[length = 2]
jsr @r0 ! 12call_valuei[length = 2]
mov r6,r8 ! 4movsi_ie/2[length = 2]
add r8,r0 ! 14*addsi3_compact[length = 2]
lds.l @r15+,pr! 37*movsi_pop/3[length = 2]
mov.l @r15+,r8! 38*movsi_pop/1[length = 2]
rts/n ! 40*return_i[length = 4]
The pop insn of r8 is not placed in the delay slot of rts without any obvious
reason. This happens only for -m1 and -m2*.
[Bug target/54083] FAIL: gcc.dg/torture/pr53922.c on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54083 John David Anglin changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #3 from John David Anglin 2012-09-16 15:45:38 UTC --- Test also fails on 32-bit hppa*-*-hpux* because undefined weak symbols are not supported. Isn't this a tree optimization bug?
[Bug fortran/54599] Issues found in gfortran by the Coverity Scan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54599
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #1 from Mikael Morin 2012-09-16
15:52:47 UTC ---
dependency.c:
1060 else
1061{
1062 gfc_symbol *sym1 = expr1->symtree->n.sym;
1063 gfc_symbol *sym2 = expr2->symtree->n.sym;
//At (1): "!sym2->attr.dimension || sym2->as->type == 2" looks like the
original copy.
//CID 721803: Copy-paste error (COPY_PASTE_ERROR)At (2): "sym2" in
//"!sym1->attr.dimension || sym2->as->type == 2" looks like a copy-paste error.
//Should it say "sym1" instead?
1064 if (sym1->attr.target && sym2->attr.target
1065 && ((sym1->attr.dummy && !sym1->attr.contiguous
1066 && (!sym1->attr.dimension
1067 || sym2->as->type == AS_ASSUMED_SHAPE))
1068 || (sym2->attr.dummy && !sym2->attr.contiguous
1069 && (!sym2->attr.dimension
1070 || sym2->as->type == AS_ASSUMED_SHAPE
1071return 1;
1072}
[Bug testsuite/54007] lto15.adb fails: gnat1: error: LTO support has not been enabled in this configuration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54007 --- Comment #3 from John David Anglin 2012-09-16 16:40:30 UTC --- Author: danglin Date: Sun Sep 16 16:40:25 2012 New Revision: 191360 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191360 Log: PR testsuite/54007 * gnat.dg/lto15.adb: Require lto. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gnat.dg/lto15.adb
[Bug debug/54460] FAIL: g++.dg/debug/dwarf2/nested-3.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54460 --- Comment #3 from John David Anglin 2012-09-16 16:43:38 UTC --- Author: danglin Date: Sun Sep 16 16:43:33 2012 New Revision: 191361 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191361 Log: PR debug/54460 * g++.dg/debug/dwarf2/nested-3.C: Add hppa assembler comment character to scary regexp. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/debug/dwarf2/nested-3.C
[Bug fortran/54597] Function can't return string without trailing spaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54597 Tobias Burnus changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #5 from Tobias Burnus 2012-09-16 17:14:32 UTC --- (In reply to comment #4) > Sorry, you are right! I have typed the wrong code, it should be > "deferred-length allocatable character" > I have post in Intel Fortran forum as > http://software.intel.com/en-us/forums/topic/326820. That matched what I suspected. As written, I can reproduce the problem with 4.7, but it has been fixed in GCC 4.8 a couple of months ago. (GCC 4.8 is the current developer version of GCC, see http://gcc.gnu.org/wiki/GFortranBinaries for information about how to build it yourself or where to obtain unofficial builds of it.) Hence, I close this bug as FIXED. Thanks nonetheless for the bug report.
[Bug debug/54460] FAIL: g++.dg/debug/dwarf2/nested-3.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54460 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from John David Anglin 2012-09-16 17:22:55 UTC --- Fixed.
[Bug rtl-optimization/54127] [4.7/4.8 Regression] ICE in maybe_record_trace_start with asm goto, --target=powerpc-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54127 Dominique d'Humieres changed: What|Removed |Added Target||powerpc*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-16 CC||jakub at gcc dot gnu.org Summary|[4.7] ICE in|[4.7/4.8 Regression] ICE in |maybe_record_trace_start|maybe_record_trace_start |with asm goto, |with asm goto, |--target=powerpc-unknown-li |--target=powerpc-unknown-li |nux-gnu |nux-gnu Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres 2012-09-16 17:46:33 UTC --- Confirmed on 4.8 (see http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg01501.html). The test has been added for 4.8 by Author: jakub Date: Tue Jun 12 07:52:47 2012 New Revision: 188428 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188428 Log: PR rtl-optimization/53589 * cfgrtl.c (force_nonfallthru_and_redirect): Do asm_goto_edge discovery even when e->dest != target. If any LABEL_REF points to e->dest label, redirect it to target's label. * gcc.dg/torture/pr53589.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr53589.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgrtl.c trunk/gcc/testsuite/ChangeLog and for 4.7 by Date: Thu Jun 14 17:49:49 2012 New Revision: 188626 The test compiles with 4.6.3, so marked as 4.7/4.8 regression.
[Bug debug/54460] FAIL: g++.dg/debug/dwarf2/nested-3.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54460 --- Comment #5 from Dominique d'Humieres 2012-09-16 17:47:56 UTC --- For the record, revision 191361 also fixes the failure on powerpc-apple-darwin9. Thanks.
[Bug target/49423] [4.6/4.7/4.8 Regression] [arm] internal compiler error: in push_minipool_fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |4.6.4
Summary|[arm] internal compiler |[4.6/4.7/4.8 Regression]
|error: in push_minipool_fix |[arm] internal compiler
||error: in push_minipool_fix
--- Comment #9 from Andrew Pinski 2012-09-16
18:10:55 UTC ---
I get this same ICE while compiling gcc.c-torture/execute/scal-to-vec2.c at -O1
with a 4.7 configured with --with-arch=armv7-a --with-fpu=vfp
--with-float=hard .
(gdb) p debug_rtx(insn)
(insn 357 1038 1041 (set (reg:SI 14 lr)
(zero_extend:SI (mem/u/c:HI (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0
S2 A16]))) t.c:49 161 {*arm_zero_extendhisi2_v6}
(nil))
$4 = void
Both arm_zero_extendhisi2 and arm_zero_extendhisi2_v6 are missing
pool_range/neg_pool_range .
[Bug fortran/54594] [OOP] Type-bound ASSIGNMENTs (elemental + array version) rejected as ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54594 --- Comment #6 from Dominique d'Humieres 2012-09-16 18:26:28 UTC --- With the patch at http://gcc.gnu.org/ml/fortran/2012-09/msg00051.html, the tests in comments #0 and #1 fails with pr54594_1.f90:6.32: generic :: assignment(=) => a_ass 1 Error: Type-bound operator at (1) can't be NOPASS Is it expected?
[Bug c++/54601] AIX uses atexit which causes unloading of shared modules to break
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54601 --- Comment #3 from Jonathan Wakely 2012-09-16 18:47:11 UTC --- To be included the patch needs to be against trunk.
[Bug fortran/54603] New: Wrong code woth structure constructor for proc-pointer components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54603 Bug #: 54603 Summary: Wrong code woth structure constructor for proc-pointer components Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: ja...@gcc.gnu.org, xarthisius...@gmail.com Created attachment 28202 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28202 Test case Reported by Kacper Kowalik via IRC. Fortran 2003 (and 2008) allow to initialize procedure-pointer components via the structure constructor, quoting F2003: "R459 component-data-source is expr or data-target or proc-target" And the latter can be per R742 and "C726 A procedure-name shall be the name of ... or a procedure pointer" I assume we either take a pointer reference too much or too little, leading to both wrong code and an ICE, depending whether we pass the name of a procedure or a procedure pointer. For this%a = ext_ptr(init, cleanup) this%a%init => init gfortran generates ext_ptr.0.init = (void (*) (void)) init; ext_ptr.0.cleanup = (void (*) (void)) cleanup; this->_data->a = ext_ptr.0; this->_data->a.init = *init; Note the missing "*" in the failing declaration. While using proc-pointers in the initialization this%a = ext_ptr(this%a%init,this%a%cleanup) gives an ICE in fold_convert_loc, bei fold-const.c:1880 The backtrace shows: #0 fold_convert_loc (loc=0, type=0x2c29f1f8, arg=) at gcc/fold-const.c:1880 #1 0x0063406b in gfc_trans_scalar_assign (lse=lse@entry=0x7fffcd70, rse=rse@entry=0x7fffcd20, ts=..., l_is_temp=l_is_temp@entry=true, deep_copy=deep_copy@entry=false, dealloc=dealloc@entry=true) at /home/tobgcc/fortran/trans-expr.c:6427 #2 0x006359b8 in gfc_trans_subcomponent_assign (expr=0x15e9210, cm=0x15e37e0, dest=0x2c27c0e0) at gcc/fortran/trans-expr.c:5588 #3 gfc_trans_structure_assign (dest=0x2c295be0, expr=, expr=) at gcc/fortran/trans-expr.c:5635
[Bug fortran/54387] [F03] Wrongly accepts non-proc result variable on the RHS of a proc-pointer assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54387 --- Comment #3 from janus at gcc dot gnu.org 2012-09-16 20:12:30 UTC --- Author: janus Date: Sun Sep 16 20:12:21 2012 New Revision: 191364 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191364 Log: 2012-09-16 Janus Weil PR fortran/54387 * expr.c (gfc_check_pointer_assign): Check for result of embracing function. 2012-09-16 Janus Weil PR fortran/54387 * gfortran.dg/proc_ptr_38.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_38.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/54387] [F03] Wrongly accepts non-proc result variable on the RHS of a proc-pointer assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54387 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from janus at gcc dot gnu.org 2012-09-16 20:19:09 UTC --- Fixed with r191364. Closing.
[Bug fortran/54594] [OOP] Type-bound ASSIGNMENTs (elemental + array version) rejected as ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54594 --- Comment #7 from janus at gcc dot gnu.org 2012-09-16 20:49:24 UTC --- Author: janus Date: Sun Sep 16 20:49:20 2012 New Revision: 191365 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191365 Log: 2012-09-16 Janus Weil PR fortran/54594 * interface.c (compare_type_rank): Handle CLASS arrays. 2012-09-16 Janus Weil PR fortran/54594 * gfortran.dg/typebound_generic_14.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_generic_14.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/54603] Wrong code with structure constructor for proc-pointer components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54603
--- Comment #1 from Tobias Burnus 2012-09-16
20:53:30 UTC ---
For
this%a = ext_ptr(this%a%init,this%a%cleanup)
and the code (in trans-expr.c)
5584 gfc_conv_expr (&se, expr);
...
5588 tmp = gfc_trans_scalar_assign (&lse, &se, cm->ts, true, false,
true);
we have
(gdb) p debug_tree (se.expr)
which is one "pointer_type" too much.
That's fixed by using:
if (gfc_expr_attr (expr).proc_pointer)
se.expr = gfc_build_addr_expr (NULL_TREE, se.expr);
However, that will fail for
this%a = ext_ptr(init, cleanup)
as those have already too much indirection.
The following patch works, but I think the proper fix has to be in
gfc_conv_variable/gfc_conv_ref.
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -5584,2 +5584,9 @@ gfc_trans_subcomponent_assign (tree dest,
gfc_conv_expr (&se, expr);
+ if (gfc_expr_attr (expr).proc_pointer)
+ {
+ if (expr->symtree->n.sym->attr.dummy && !expr->ref)
+ se.expr = build_fold_indirect_ref_loc (input_location, se.expr);
+ else
+ se.expr = gfc_build_addr_expr (NULL_TREE, se.expr);
+ }
if (cm->ts.type == BT_CHARACTER)
[Bug fortran/54594] [OOP] Type-bound ASSIGNMENTs (elemental + array version) rejected as ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54594 --- Comment #8 from janus at gcc dot gnu.org 2012-09-16 21:07:23 UTC --- (In reply to comment #6) > With the patch at http://gcc.gnu.org/ml/fortran/2012-09/msg00051.html, the > tests in comments #0 and #1 fails with > > pr54594_1.f90:6.32: > > generic :: assignment(=) => a_ass > 1 > Error: Type-bound operator at (1) can't be NOPASS > > Is it expected? That's a good question. I could not find that restriction in the standard on a quick check. In any case, the error message comes from 'get_checked_tb_operator_target' (resolve.c), which was committed in r150856 for PR 37435.
[Bug fortran/54603] [F03] Wrong code with structure constructor for proc-pointer components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54603 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-16 Summary|Wrong code with structure |[F03] Wrong code with |constructor for |structure constructor for |proc-pointer components |proc-pointer components Ever Confirmed|0 |1 --- Comment #2 from janus at gcc dot gnu.org 2012-09-16 21:19:09 UTC --- Here is a reduced test case for the ICE: implicit none type :: ext_ptr procedure(), nopass, pointer :: init end type type(ext_ptr) :: this this = ext_ptr(this%init) ! ICE in fold_convert_loc end
[Bug fortran/54603] [F03] Wrong code with structure constructor for proc-pointer components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54603 --- Comment #3 from janus at gcc dot gnu.org 2012-09-16 21:21:56 UTC --- Loosely related: PR 50438.
[Bug fortran/54594] [OOP] Type-bound ASSIGNMENTs (elemental + array version) rejected as ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54594 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #9 from Tobias Burnus 2012-09-16 21:25:18 UTC --- (In reply to comment #8) > > Is it expected? (Both the original example and the one of comment 1 do compile and run with crayftn.) > That's a good question. I could not find that restriction in the standard on a > quick check. In any case, the error message comes from > 'get_checked_tb_operator_target' (resolve.c), which was committed in r150856 That's PR 37425 (you had one digit wrong). The constraint is (F2008): C468 (R450) If generic-spec is not generic-name, each of its specific bindings shall have a passed-object dummy argument (4.5.4.5). with R1207 generic-spec is generic-name or OPERATOR ( de ned-operator ) or ASSIGNMENT ( = ) or defined-io-generic-spec
[Bug fortran/54594] [OOP] Type-bound ASSIGNMENTs (elemental + array version) rejected as ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54594
--- Comment #10 from janus at gcc dot gnu.org 2012-09-16 21:38:23 UTC ---
(In reply to comment #9)
> The constraint is (F2008):
>
> C468 (R450) If generic-spec is not generic-name, each of its specific bindings
> shall have a passed-object dummy argument (4.5.4.5).
>
> with
>
> R1207 generic-spec is generic-name
> or OPERATOR ( de ned-operator )
> or ASSIGNMENT ( = )
> or defined-io-generic-spec
Thanks for finding the reference. I looked in the right spot, but somehow
overread it, due to the 'indirect' wording.
I will commit the following docu-patch as obvious:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 191364)
+++ gcc/fortran/resolve.c (working copy)
@@ -11429,7 +11429,7 @@
target_proc = target->specific->u.specific->n.sym;
gcc_assert (target_proc);
- /* All operator bindings must have a passed-object dummy argument. */
+ /* F08:C468. All operator bindings must have a passed-object dummy argument.
*/
if (target->specific->nopass)
{
gfc_error ("Type-bound operator at %L can't be NOPASS", &where);
[Bug fortran/54594] [OOP] Type-bound ASSIGNMENTs (elemental + array version) rejected as ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54594 --- Comment #11 from janus at gcc dot gnu.org 2012-09-16 22:04:30 UTC --- Author: janus Date: Sun Sep 16 22:04:26 2012 New Revision: 191366 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191366 Log: 2012-09-16 Janus Weil PR fortran/54594 * resolve.c (get_checked_tb_operator_target): Add a reference to the relevant quote from the F08 standard. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c
[Bug fortran/54594] [OOP] Type-bound ASSIGNMENTs (elemental + array version) rejected as ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54594 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from janus at gcc dot gnu.org 2012-09-16 22:06:30 UTC --- (In reply to comment #6) > Error: Type-bound operator at (1) can't be NOPASS > > Is it expected? After this is settled (the answer being yes), I'll close this PR, since the original problem was fixed with r191365.
[Bug fortran/54572] Use libbacktrace library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572 --- Comment #3 from Hans-Peter Nilsson 2012-09-16 23:16:02 UTC --- (In reply to comment #2) > (In reply to comment #1) > > You need unwind frames present for this to work, > How is this different from the current backtracing implementation in > libgfortran? Right, it already has that dependence, sorry for the noise.
[Bug c++/54604] New: ICE (segv) calling explicitly member function template specialization in a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54604
Bug #: 54604
Summary: ICE (segv) calling explicitly member function template
specialization in a lambda
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: delon...@fb.com
Small repro case:
% cat crash.cpp
class C {
public:
template void f() { }
template void g() {
auto foo = [&]() { f(); };
}
};
int main() {
C c;
c.g();
}
% g++_4.7 -std=gnu++0x crash.cpp
crash.cpp: In instantiation of ‘C::g() [with bool Fun = false]::’:
crash.cpp:5:18: required from ‘struct C::g() [with bool Fun =
false]::’
crash.cpp:5:34: required from ‘void C::g() [with bool Fun = false]’
crash.cpp:11:15: required from here
crash.cpp:5:24: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
[Bug middle-end/54605] New: MIPS64 ICEs while building libgfortran for n32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54605 Bug #: 54605 Summary: MIPS64 ICEs while building libgfortran for n32 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: build, ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: pins...@gcc.gnu.org Target: mips64-linux-gnu (insn 28 27 29 2 (set (parallel:TF [ (expr_list:REG_DEP_TRUE (reg:DI 204) (const_int 0 [0])) (expr_list:REG_DEP_TRUE (reg:DI 205) (const_int 8 [0x8])) ]) (subreg:TF (reg:TI 209) 0)) /home/apinski/src/gcc-fsf/local/gcc/libgfortran/generated/_mod_r16.F90:41 -1 (nil)) /home/apinski/src/gcc-fsf/local/gcc/libgfortran/generated/_mod_r16.F90:42:0: internal compiler error: in extract_insn, at recog.c:2125 Please submit a full bug report, Last revision which is known to work: 190863 There is a revision after that worked but I don't have a record as my machine crashed due to an Ethernet driver bug.
[Bug middle-end/54605] [4.8 Regression] MIPS64 ICEs while building libgfortran for n32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54605 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.8.0 Summary|MIPS64 ICEs while building |[4.8 Regression] MIPS64 |libgfortran for n32 |ICEs while building ||libgfortran for n32
[Bug middle-end/54605] [4.8 Regression] MIPS64 ICEs while building libgfortran for n32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54605 --- Comment #1 from Andrew Pinski 2012-09-17 04:42:51 UTC --- Ok, the last revision it worked was 191233 .
[Bug middle-end/54605] [4.8 Regression] MIPS64 ICEs while building libgfortran for n32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54605 --- Comment #2 from Andrew Pinski 2012-09-17 04:50:03 UTC --- Actually I think this is fixed by: 2012-09-16 Richard Sandiford * calls.c (expand_call): Use emit_group_move for PARALLEL->PARALLEL moves.
