[Bug libstdc++/49561] [C++0x] std::list::size complexity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.7.0 |---
[Bug rtl-optimization/52543] lower-subreg.c: code bloat of 300%-400% for multi-word memory splits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52543 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.7.1 |---
[Bug driver/53002] Request new specs string token for multilib_os_dir
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53002 --- Comment #4 from Steven Drake sbd at NetBSD dot org 2012-09-15 07:13:36 UTC --- (In reply to comment #3) Patch commited in svn id 87775. Correction that should be svn id 187775
[Bug testsuite/53739] FAIL: g++.dg/init/null1.C -std=c++11 happens even though it should not be tested
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53739 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-09-15 07:16:54 UTC --- This was due to my board not doing: process_multilib_options
[Bug middle-end/54315] Unnecessary copy of return value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54315 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-09-15 08:23:41 UTC --- I'll try to improve things on x86-64 at least.
[Bug tree-optimization/54525] Recognize (vec_)cond_expr in mask operation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54525 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org 2012-09-15 08:28:08 UTC --- (In reply to comment #0) vpcmpgtq%xmm2, %xmm3, %xmm2 vpcmpeqd%xmm3, %xmm3, %xmm3 [...] (also notice that for some reason all comparisons (I tried = = and even with a ~ in front) generate a combination of gt and eq, never just gt) Hmm, that remark was nonsense, the eq has nothing to do with the gt, it is just the way the compiler generates a constant -1 vector so it can then xor with it to compute a ~.
[Bug c++/54575] [4.8 Regression] ICE with std::vector::insert and -std=c++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54575 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|NEW
[Bug other/54500] While(TRUE) loop optimization of global struct variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54500 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Target|avr-* |avr Last reconfirmed|2012-09-06 00:00:00 | Component|c |other Build|WinAVR 20081205 | Severity|major |normal
[Bug target/50256] AVR GCC - several unnecessary register moves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50256 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Last reconfirmed|2011-09-01 00:00:00 | Resolution||INVALID --- Comment #7 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-09-15 09:29:46 UTC --- Closed. There is still no test case for over one year now.
[Bug target/54516] [4.8 regression] ICE in reload_cse_simplify_operands, at postreload.c:403 with -O1 -march=armv7-a -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54516 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-09-15 09:55:12 UTC --- Fixed
[Bug rtl-optimization/54540] [4.8 regression] postreload incorrectly simplifies stack adjustment into constant load into SP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54540 --- Comment #4 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-09-15 09:57:34 UTC --- (In reply to comment #3) Author: rearnsha Date: Fri Sep 14 17:10:45 2012 New Revision: 191307 Has probably made the post-reload issues go latent again.
[Bug fortran/54572] Use libbacktrace library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-09-15 11:25:35 UTC --- 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.)
[Bug c/54587] New: Error with constant in arithmetic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54587 Bug #: 54587 Summary: Error with constant in arithmetic Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: bratsi...@gmail.com If i enter: printf(%x, 0x404e-0x4043); GCC give me error: test.c: In function ‘main’: test.c:164:15: error: invalid suffix -0x4043 on integer constant If write: printf(%x, 0x404e - 0x4043); everything all right.
[Bug c/54587] Error with constant in arithmetic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54587 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2012-09-15 12:02:04 UTC --- . *** This bug has been marked as a duplicate of bug 3885 ***
[Bug c/3885] Incorrect invalid suffix on integer constant error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3885 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added CC||bratsinot at gmail dot com --- Comment #11 from Andreas Schwab sch...@linux-m68k.org 2012-09-15 12:02:04 UTC --- *** Bug 54587 has been marked as a duplicate of this bug. ***
[Bug c/51840] asm goto enhancement request
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51840
--- Comment #4 from Timo Kreuzer timo.kreuzer at reactos dot org 2012-09-15
12:16:38 UTC ---
Update: I fought a bit with GCC and made clear that my Kung Fu is better than
GCC's ;-)
I solved this issue with a workaround. I forced a number of constraints upon
GCC, that made it cry and stop shuffling the code around. These constraints
will make certain optimizations by moving code around useless, so assuming that
gcc will do the right thing, it won't move code onto pathes between the asm
goto and the actual label address.
So here's my code:
int
example1(int param)
{
int value = 0;
if (param 2)
{
label1:
asm goto (movl %0, %%ecx\n\tjmp %l[label3]\n : : i(label3) :
ecx : label3, labelx);
}
value = 1;
if (param 1)
{
label2:
asm goto (movl %0, %%ecx\n\tjmp %l[label3]\n : : i(label3) :
ecx : label3, labelx);
}
value = 2;
label3:
return value;
labelx:(void)0;
void *plabel;
asm volatile (# : =a(plabel) : p(label1), p(label2),
p(label3), p(labelx) : memory);
goto *plabel;
}
Almost the same as before, with exception to the additional labelx construct.
First the asm instruction makes GCC think the addresses of all the labels might
be used here and after it we have plabel being eax containing something that
GCC doesn't know anything about.
The goto basically tells GCC that there are pathes between these labels.
GCC won't insert any lazy evaluation of constants into a codepath between
label1 and the static label3 address, because due to the additional asm goto
reference to labelx, it would need to add this code in the path between label1
and labelx as well. But since there is a virtual goto from labelx back to
label1, it would put the code into the inner of a loop, which it will try to
avoid.
Anyway this is a huge hack and works rather on the principle of good faith,
than on hard specifications.
Maybe someone finds an approach that is proovable to result in the right thing.
Or some gcc dev does the right thing and fixes asm goto.
[Bug fortran/36825] [F2008] Rank 7 arrays [will break library ABI] libgfortran I/O+intrinsics:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36825
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #12 from Tobias Burnus burnus at gcc dot gnu.org 2012-09-15
13:09:15 UTC ---
We also need to update dwarf2out.h, which has:
266struct array_descr_info
267{
268 int ndimensions;
269 tree element_type;
270 tree base_decl;
271 tree data_location;
272 tree allocated;
273 tree associated;
274 struct array_descr_dimen
275{
276 tree lower_bound;
277 tree upper_bound;
278 tree stride;
279} dimen[10];
280};
Thus, GCC limits the maximal rank to 10.
[Bug tree-optimization/54589] New: [missed-optimization] struct offset add should be folded into address calculation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589
Bug #: 54589
Summary: [missed-optimization] struct offset add should be
folded into address calculation
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sgunder...@bigfoot.com
Hi,
I found this in 4.4 (Ubuntu 10.04), and have confirmed it's still there in
gcc (Debian 20120820-1) 4.8.0 20120820 (experimental) [trunk revision 190537]
This code:
#include emmintrin.h
struct param {
int a, b, c, d;
__m128i array[256];
};
void func(struct param *p, unsigned char *src, int *dst)
{
__m128i x = p-array[*src];
*dst = _mm_cvtsi128_si32(x);
}
compiles with -O2 on x86-64 to this assembler:
func:
0:0f b6 06 movzbl (%rsi),%eax
3:48 83 c0 01 add$0x1,%rax
7:48 c1 e0 04 shl$0x4,%rax
b:8b 04 07 mov(%rdi,%rax,1),%eax
e:89 02mov%eax,(%rdx)
10:c3 retq
The add should be folded into the address calculation here. (The shl can't,
because it's too big.) Curiously enough, if I misalign the struct element by
removing c and d, and declaring the struct __attribute__((packed)), GCC will do
that; the mov will then be from $8(%rdi,%rax,1),%eax and there is no redundant
add.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #141 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-09-15 14:05:38 UTC --- After the new IonMonkey JIT went in (http://blog.mozilla.org/javascript/2012/09/12/ionmonkey-in-firefox-18/) peak memory use went up. It is now 6.8GB (gcc-4.7 roughly the same: 6.5GB). So we're approaching the point where a 8GB machine isn't enough to build Firefox with LTO...
[Bug c++/54590] New: Incorrect multi-inheritence bases layout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54590
Bug #: 54590
Summary: Incorrect multi-inheritence bases layout
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wingf...@gmail.com
the code:
#include iostream
struct A{ virtual void foo() {} };
struct B { void * data; };
struct X : public B, A { };
int main(){
X x;
if((void*)x == (void*)(x.data))
std::cout correct\n;
else
std::cout oops...\n;
return 0;
}
Expect:
print correct
Result:
print oops...
Notes:
if A::foo is not virtual, the result is correct.
[Bug c++/54591] New: sscanf format no more working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54591
Bug #: 54591
Summary: sscanf format no more working
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: temp78...@mutluit.com
sscanf no more working, it was ok in prev. versions:
#include cstdio
#include cstdlib
int main()
{
const char*psz = PROTO=TCP SPT=6004 DPT=26532 ;
char szProto[256] = ;
unsigned short usSrcPort = 0, usDstPort = 0;
const int c = sscanf(psz, PROTO=%255[^ \t\n]s SPT=%hu DPT=%hu, szProto,
usSrcPort, usDstPort);
printf(%s\n, c == 3 ? OK : ERROR);
//...
return 0;
}
It fills only the first field -- c=1 -- ERROR
This code was working fine in prev. compiler versions.
# g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.1-2'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.1 (Debian 4.7.1-2)
[Bug c++/54590] Incorrect multi-inheritence bases layout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54590 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2012-09-15 15:02:12 UTC --- The first word contains a pointer to the vtable for X.
[Bug tree-optimization/54592] New: [4.8 Regression] [missed-optimization] Cannot fuse SSE move and add together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54592
Bug #: 54592
Summary: [4.8 Regression] [missed-optimization] Cannot fuse SSE
move and add together
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sgunder...@bigfoot.com
Hi,
I have, on x86-64,
gcc version 4.7.1 (Debian 4.7.1-9)
gcc version 4.8.0 20120820 (experimental) [trunk revision 190537] (Debian
20120820-1)
Given the following test program:
#include emmintrin.h
void func(__m128i *foo, size_t a, size_t b, int *dst)
{
__m128i x = foo[a];
__m128i y = foo[b];
__m128i sum = _mm_add_epi32(x, y);
*dst = _mm_cvtsi128_si32(sum);
}
GCC 4.8 with -O2 compiles it to
0:48 c1 e6 04 shl$0x4,%rsi
4:48 c1 e2 04 shl$0x4,%rdx
8:66 0f 6f 0c 17 movdqa (%rdi,%rdx,1),%xmm1
d:66 0f 6f 04 37 movdqa (%rdi,%rsi,1),%xmm0
12:66 0f fe c1 paddd %xmm1,%xmm0
16:66 0f 7e 01 movd %xmm0,(%rcx)
1a:c3 retq
The mov into %xmm1 here doesn't seem to make sense; it should rather be
paddd-ed in directly. And indeed, GCC 4.7 with -O2 gets this right:
0:48 c1 e6 04 shl$0x4,%rsi
4:48 c1 e2 04 shl$0x4,%rdx
8:66 0f 6f 04 37 movdqa (%rdi,%rsi,1),%xmm0
d:66 0f fe 04 17 paddd (%rdi,%rdx,1),%xmm0
12:66 0f 7e 01 movd %xmm0,(%rcx)
16:c3 retq
This would seem like a regression to me.
[Bug target/54222] [avr] Implement fixed-point support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54222 --- Comment #6 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-09-15 15:52:35 UTC --- Author: gjl Date: Sat Sep 15 15:52:28 2012 New Revision: 191345 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191345 Log: gcc/ PR target/54222 * config/avr/avr-fixed.md (ALL2S, ALL4S, ALL24S, ALL124S, ALL124U): New mode iterators. (code_stdnamemode3): New insns for SS_PLUS, SS_MINUS. (code_stdnamemode3): New insns for US_PLUS, US_MINUS. (usnegmode2): New insns. (code_stdnamemode2): New expanders for SS_NEG, SS_ABS. (*code_stdnamemode2): New insns for SS_NEG, SS_ABS. * config/avr/avr-dimode.md (ALL8U, ALL8S): New mode iterators. (avr_out_plus64, avr_out_minus64): Use avr_out_plus instead. (code_stdnamemode3): New expanders for SS_PLUS, SS_MINUS. (code_stdnamemode3): New expanders for US_PLUS, US_MINUS. (code_stdnamemode3_insn): New insns. (code_stdnamemode3_const_insn): New insns. * config/avr/avr.md (cc): Add: plus. Remove: out_plus, out_plus_noclobber, minus. (length): Add: plus. Remove: out_plus, out_plus_noclobber, plus64, minus, minus64. (abelian): New code_attr. (code_stdname): Handle: ss_plus, ss_minus, ss_neg, ss_abs, us_plus, us_minus, us_neg. (*addmode3, addmode3_clobber, addmode3, addpsi3, submode3): Use avr_out_plus to output. * config/avr/avr-protos.h (avr_out_plus): Change prototype. (avr_out_plus_noclobber, avr_out_minus): Remove. (avr_out_plus64, avr_out_minus64): Remove. * config/avr/avr.c (avr_out_plus_1): Add new default arguments code_sat, sign. Saturate after operation if code_sat != UNKNOWN. (avr_out_plus_symbol): New static function. (avr_out_plus): Rewrite. (adjust_insn_length): Handle: ADJUST_LEN_PLUS. Remove handling of: ADJUST_LEN_OUT_PLUS, ADJUST_LEN_PLUS64, ADJUST_LEN_MINUS, ADJUST_LEN_MINUS64, ADJUST_LEN_OUT_PLUS_NOCLOBBER. (notice_update_cc): Handle: CC_PLUS. Remove handling of: CC_MINUS, CC_OUT_PLUS, CC_OUT_PLUS_NOCLOBBER (avr_out_plus_noclobber, avr_out_minus): Remove. (avr_out_plus64, avr_out_minus64): Remove. (avr_print_operand): Print raw REGNO if 'r' is used with REG. libgcc/ PR target/54222 * config/avr/lib1funcs-fixed.S (__ssneg_2, __ssabs_2, __ssneg_4, __ssabs_4, __clr_8, __ssneg_8, __ssabs_8, __usadd_8, __ussub_8, __ssadd_8, __sssub_8): New functions. (__divsa3): Use __negsi2 to negate r_quoL. * config/avr/lib1funcs.S (FALIAS): New macro. (__divmodsi4): Break out and use __divmodsi4_neg1 as... (__negsi2): ...this new function. * config/avr/t-avr (LIB1ASMFUNCS): Add _negsi2, _clr_8, _ssneg_2, _ssneg_4, _ssneg_8, _ssabs_2, _ssabs_4, _ssabs_8, _ssadd_8, _sssub_8, _usadd_8, _ussub_8. (LIB2FUNCS_EXCLUDE): Fix typo for _add _sub. Add: _ssadd*, _sssub*, _ssneg*, _ssabs* for signed fixed modes. Add: _usadd*, _ussub*, _usneg* for unsigned fixed modes. gcc/testsuite/ PR target/54222 * gcc.target/avr/torture/fix-types.h: New. * gcc.target/avr/torture/vals-hr.def: New. * gcc.target/avr/torture/vals-r.def: New. * gcc.target/avr/torture/vals-k.def: New. * gcc.target/avr/torture/vals-ur.def: New. * gcc.target/avr/torture/vals-uk.def: New. * gcc.target/avr/torture/vals-uhr.def: New. * gcc.target/avr/torture/vals-llk.def: New. * gcc.target/avr/torture/vals-ullk.def: New. * gcc.target/avr/torture/sat-hr-plus-minus.c: New. * gcc.target/avr/torture/sat-r-plus-minus.c: New. * gcc.target/avr/torture/sat-k-plus-minus.c: New. * gcc.target/avr/torture/sat-ur-plus-minus.c: New. * gcc.target/avr/torture/sat-uk-plus-minus.c: New. * gcc.target/avr/torture/sat-uhr-plus-minus.c: New. * gcc.target/avr/torture/sat-llk-plus-minus.c: New. * gcc.target/avr/torture/sat-ullk-plus-minus.c: New. Added: trunk/gcc/testsuite/gcc.target/avr/torture/fix-types.h trunk/gcc/testsuite/gcc.target/avr/torture/sat-hr-plus-minus.c trunk/gcc/testsuite/gcc.target/avr/torture/sat-k-plus-minus.c trunk/gcc/testsuite/gcc.target/avr/torture/sat-llk-plus-minus.c trunk/gcc/testsuite/gcc.target/avr/torture/sat-r-plus-minus.c trunk/gcc/testsuite/gcc.target/avr/torture/sat-uhr-plus-minus.c trunk/gcc/testsuite/gcc.target/avr/torture/sat-uk-plus-minus.c trunk/gcc/testsuite/gcc.target/avr/torture/sat-ullk-plus-minus.c trunk/gcc/testsuite/gcc.target/avr/torture/sat-ur-plus-minus.c trunk/gcc/testsuite/gcc.target/avr/torture/vals-hr.def trunk/gcc/testsuite/gcc.target/avr/torture/vals-k.def trunk/gcc/testsuite/gcc.target/avr/torture/vals-llk.def trunk/gcc/testsuite/gcc.target/avr/torture/vals-r.def trunk/gcc/testsuite/gcc.target/avr/torture/vals-uhr.def trunk/gcc/testsuite/gcc.target/avr/torture/vals-uk.def trunk/gcc/testsuite/gcc.target/avr/torture/vals-ullk.def trunk/gcc/testsuite/gcc.target/avr/torture/vals-ur.def Modified:
[Bug target/42778] Superfluous stack management code is generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42778 sgunderson at bigfoot dot com changed: What|Removed |Added CC||sgunderson at bigfoot dot ||com --- Comment #3 from sgunderson at bigfoot dot com 2012-09-15 16:02:37 UTC --- This seems to be no longer wrong in 4.8.
[Bug target/54593] New: [missed-optimization] Move from SSE to integer register goes through the stack without -march=native
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54593
Bug #: 54593
Summary: [missed-optimization] Move from SSE to integer
register goes through the stack without -march=native
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sgunder...@bigfoot.com
Hi,
I have reproduced this on 4.4, 4.6, 4.7 and 4.8 (Debian 20120820-1, trunk
version 190537). Given the following code:
#include x86intrin.h
int test1(__m128i v) {
return _mm_cvtsi128_si32(v);
}
GCC generates
0:66 0f 7e 44 24 f4movd %xmm0,-0xc(%rsp)
6:8b 44 24 f4 mov-0xc(%rsp),%eax
a:c3 retq
Shouldn't it go directly to %eax instead of through the stack? Granted, on
Netburst this takes ten cycles or so, but this is x86-64. It appears to be some
sort of tuning issue, since if I use -mtune=native (I am on an Atom) I get:
0:66 0f 7e c0 movd %xmm0,%eax
4:90 nop
5:90 nop
6:90 nop
7:90 nop
8:90 nop
9:90 nop
a:c3 retq
which is sort-of what I expect. Well, the NOPs are a bit weird, but... :-)
[Bug target/54593] [missed-optimization] Move from SSE to integer register goes through the stack without -march=native
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54593 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-09-15 16:35:43 UTC --- This depends on the actually x86 processor. On AMD processors, it is better to go through memory than going direct.
[Bug target/54593] [missed-optimization] Move from SSE to integer register goes through the stack without -march=native
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54593 --- Comment #2 from sgunderson at bigfoot dot com 2012-09-15 16:38:34 UTC --- Interesting. So it's a conscious choice that “generic” does this?
[Bug c++/54591] sscanf format no more working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54591 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Severity|critical|normal --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-09-15 16:45:56 UTC --- GCC is not involved here but rather the library glibc is what is different. Make sure you are doing something which is valid C/C++ before submitting it to glibc.
[Bug c++/54588] Improved error messages by dropping out types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54588 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-09-15 16:46:55 UTC --- We just were adding the types lately.
[Bug target/54593] [missed-optimization] Move from SSE to integer register goes through the stack without -march=native
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54593 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-09-15 16:50:31 UTC --- (In reply to comment #2) Interesting. So it's a conscious choice that “generic” does this? Yes: /* X86_TUNE_SSE_PARTIAL_REG_DEPENDENCY: In the Generic model we have a conflict here in between PPro/Pentium4 based chips that thread 128bit SSE registers as single units versus K8 based chips that divide SSE registers to two 64bit halves. This knob promotes all store destinations to be 128bit to allow register renaming on 128bit SSE units, but usually results in one extra microop on 64bit SSE units. Experimental results shows that disabling this option on P4 brings over 20% SPECfp regression, while enabling it on K8 brings roughly 2.4% regression that can be partly masked by careful scheduling of moves. */ m_PPRO | m_P4_NOCONA | m_CORE2I7 | m_ATOM | m_AMDFAM10 | m_BDVER | m_GENERIC,
[Bug target/54593] [missed-optimization] Move from SSE to integer register goes through the stack without -march=native
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54593 --- Comment #4 from sgunderson at bigfoot dot com 2012-09-15 16:54:28 UTC --- I'm not sure if I understand the comment very well; it talks about Pentium 4, but none of them run 64-bit code, do they?
[Bug fortran/54224] [4.8 Regression] Bogus -Wunused-function warning with static function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54224 janus at gcc dot gnu.org changed: What|Removed |Added Component|middle-end |fortran --- Comment #7 from janus at gcc dot gnu.org 2012-09-15 17:41:29 UTC --- (In reply to comment #6) * It seems as if the TREE_USED part should be handled on the Fortran FE side for both (PRIVATE) module variables and module procedures Here is a patch which should set TREE_USED for all procedure calls: Index: gcc/fortran/trans-expr.c === --- gcc/fortran/trans-expr.c(revision 191303) +++ gcc/fortran/trans-expr.c(working copy) @@ -2455,6 +2455,8 @@ conv_function_val (gfc_se * se, gfc_symbol * sym, if (!sym-backend_decl) sym-backend_decl = gfc_get_extern_function_decl (sym); + TREE_USED (sym-backend_decl) = 1; + tmp = sym-backend_decl; if (sym-attr.cray_pointee) It makes the bogus warning on comment 0 go away.
[Bug fortran/54224] [4.8 Regression] Bogus -Wunused-function warning with static function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54224 --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2012-09-15 17:47:37 UTC --- (In reply to comment #7) Here is a patch which should set TREE_USED for all procedure calls: Does it still allow to optimize unused PRIVATE module procedures away?
[Bug c++/54580] 64-bit pointer to int cast fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54580 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-15 17:52:43 UTC --- That explicit type conversion (i.e. cast) is equivalent to reinterpret_castint() and the standard says reinterpret_cast can be used to convert a pointer to an integer type large enough to hold it. The code is invalid and should be rejected by any 64-bit C++ compiler, just as (short) should be by 32-bit compilers.
[Bug c++/54580] 64-bit pointer to int cast fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54580 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-15 17:57:52 UTC --- Or strictly, should be rejected by any 64-bit compiler with 32-bit int (which is practically all of them) and any 32-bit compiler with 16-bit short. Certainly invalid for g++ on LP64 platforms.
[Bug fortran/54594] New: [OOP] Type-bound ASSIGNMENTs (elemental + array version) rejected as ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54594 Bug #: 54594 Summary: [OOP] Type-bound ASSIGNMENTs (elemental + array version) rejected as ambiguous Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: ja...@gcc.gnu.org Created attachment 28197 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28197 generic_defined_assignment.f90 (Note, I haven't checked whether the following bug report is valid.= The following program by James Van Buskirk compiles with Cray ftn and prints: Explicit calls: Overloaded Overloaded Overloaded Implicit calls: Overloaded array-array Overloaded scalar-array Overloaded However, it fails with gfortran with the error: generic :: assignment(=) = a_ass 1 Error: 'a_ass' and 'a_ass_sv' for GENERIC '=' at (1) are ambiguous Note for the defined assignment, you need the patch for PR46897, cf. http://gcc.gnu.org/ml/fortran/2012-09/msg00034.html See also discussion at https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/5eAz5ns6AG0
[Bug fortran/54224] [4.8 Regression] Bogus -Wunused-function warning with static function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54224 --- Comment #10 from janus at gcc dot gnu.org 2012-09-15 18:26:27 UTC --- (In reply to comment #8) Here is a patch which should set TREE_USED for all procedure calls: Does it still allow to optimize unused PRIVATE module procedures away? I think so. conv_function_val is only called by gfc_conv_procedure_call. If the procedure is really not used, then gfc_conv_procedure_call will not be called, and thus also TREE_USED will not be set. Moreover, the patchlet in comment 7 seems to be free of testsuite regressions.
[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|UNCONFIRMED |NEW Last reconfirmed||2012-09-15 Ever Confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org 2012-09-15 18:39:40 UTC --- Here is a reduced version of the test case: module a_mod type :: a contains procedure, NOPASS :: a_ass, a_ass_sv generic :: assignment(=) = a_ass, a_ass_sv end type contains impure elemental subroutine a_ass (out, in) class(a), intent(out) :: out type(a), intent(in) :: in end subroutine subroutine a_ass_sv (out, in) class(a), intent(out) :: out(:) type(a), intent(in) :: in end subroutine end module
[Bug fortran/54594] [OOP] Type-bound ASSIGNMENTs (elemental + array version) rejected as ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54594 --- Comment #2 from janus at gcc dot gnu.org 2012-09-15 18:46:06 UTC --- Note: The same error appears also for a non-typebound generic interface: module a_mod type :: a end type interface ass procedure :: a_ass, a_ass_sv end interface contains impure elemental subroutine a_ass (out, in) class(a), intent(out) :: out type(a), intent(in) :: in end subroutine subroutine a_ass_sv (out, in) class(a), intent(out) :: out(:) type(a), intent(in) :: in end subroutine end module
[Bug libstdc++/54591] sscanf format no more working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54591 Uenal Mutlu temp78593 at mutluit dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Component|c++ |libstdc++ Resolution|INVALID | Severity|normal |critical --- Comment #2 from Uenal Mutlu temp78593 at mutluit dot com 2012-09-15 18:58:25 UTC --- moving the bugreport to libstdc++.
[Bug libstdc++/54591] sscanf format no more working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54591 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Andreas Schwab sch...@linux-m68k.org 2012-09-15 19:03:44 UTC --- libstdc++ is not glibc.
[Bug fortran/54594] [OOP] Type-bound ASSIGNMENTs (elemental + array version) rejected as ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54594 --- Comment #3 from janus at gcc dot gnu.org 2012-09-15 20:05:53 UTC --- (In reply to comment #2) Note: The same error appears also for a non-typebound generic interface: ... also if the second argument 'in' is removed from both procedures. However, the test case is accepted if the CLASS declarations are changed to TYPE: module a_mod type :: a end type interface ass procedure :: a_ass, a_ass_sv end interface contains impure elemental subroutine a_ass (out) type(a), intent(out) :: out end subroutine subroutine a_ass_sv (out) type(a), intent(out) :: out(:) end subroutine end module
[Bug target/54593] [missed-optimization] Move from SSE to integer register goes through the stack without -march=native
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54593 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2012-09-15 20:17:24 UTC --- (In reply to comment #4) I'm not sure if I understand the comment very well; it talks about Pentium 4, but none of them run 64-bit code, do they? Wrong quote. It should be /* X86_TUNE_INTER_UNIT_MOVES */ ~(m_AMD_MULTIPLE | m_GENERIC),
[Bug target/54593] [missed-optimization] Move from SSE to integer register goes through the stack without -march=native
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54593 --- Comment #6 from sgunderson at bigfoot dot com 2012-09-15 20:28:02 UTC --- Ah. So basically it hurts AMD enough (the opposite doesn't hit Intel enough) that the choice was made to make it that way generic too. Well, as long as it's a deliberate choice, I assume it's a reasonable tradeoff, so thanks for the enlightenment. :-)
[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|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
--- Comment #4 from janus at gcc dot gnu.org 2012-09-15 21:02:17 UTC ---
Apparently the problem is that gfc_compare_types does not handle CLASS arrays
properly. The following patch should fix it (it makes gfortran accept the test
case):
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c(revision 191303)
+++ gcc/fortran/interface.c(working copy)
@@ -507,14 +507,18 @@ gfc_compare_types (gfc_typespec *ts1, gfc_typespec
static int
compare_type_rank (gfc_symbol *s1, gfc_symbol *s2)
{
+ gfc_array_spec *as1, *as2;
int r1, r2;
- r1 = (s1-as != NULL) ? s1-as-rank : 0;
- r2 = (s2-as != NULL) ? s2-as-rank : 0;
+ as1 = (s1-ts.type == BT_CLASS) ? CLASS_DATA (s1)-as : s1-as;
+ as2 = (s2-ts.type == BT_CLASS) ? CLASS_DATA (s2)-as : s2-as;
+ r1 = as1 ? as1-rank : 0;
+ r2 = as2 ? as2-rank : 0;
+
if (r1 != r2
- (!s1-as || s1-as-type != AS_ASSUMED_RANK)
- (!s2-as || s2-as-type != AS_ASSUMED_RANK))
+ (!as1 || as1-type != AS_ASSUMED_RANK)
+ (!as2 || as2-type != AS_ASSUMED_RANK))
return 0;/* Ranks differ. */
return gfc_compare_types (s1-ts, s2-ts)
Regtesting now ...
[Bug fortran/54594] [OOP] Type-bound ASSIGNMENTs (elemental + array version) rejected as ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54594 --- Comment #5 from janus at gcc dot gnu.org 2012-09-15 21:53:49 UTC --- (In reply to comment #4) Regtesting now ... ... finished without failures.
[Bug debug/54595] New: [4.8 Regression] symbol causes a section type conflict with itself with -O -g -fdata-section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54595 Bug #: 54595 Summary: [4.8 Regression] symbol causes a section type conflict with itself with -O -g -fdata-section Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: bernhard.rosenkran...@linaro.org Created attachment 28198 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28198 Preprocessed source, gzipped because it's huge Compiling llvm with -O -g -fdata-section results in $ /opt/android-toolchain-trunk/bin/arm-linux-androideabi-g++ -O -g -fdata-sections -c FunctionAttrs.i -o out/target/product/maguro/obj/STATIC_LIBRARIES/libLLVMipo_intermediates/FunctionAttrs.o In file included from external/llvm/include/llvm/Argument.h:18:0, from external/llvm/include/llvm/Function.h:24, from external/llvm/include/llvm/Analysis/CallGraph.h:54, from external/llvm/include/llvm/CallGraphSCCPass.h:25, from external/llvm/lib/Transforms/IPO/FunctionAttrs.cpp:23: external/llvm/include/llvm/Attributes.h:113:52: error: llvm::Attribute::ReadOnly causes a section type conflict with llvm::Attribute::ReadOnly DECLARE_LLVM_ATTRIBUTE(ReadOnly,110) /// Function only reads from memory ^ I haven't tried to isolate the cause/reduce the test case yet; this might be a dupe of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53475
[Bug c++/54596] New: seg fault building Eigen stuff with cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54596 Bug #: 54596 Summary: seg fault building Eigen stuff with cygwin Classification: Unclassified Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dou...@sprynet.com In cygwin, running: /bin/c++.exe -Dtypes_sba_EXPORTS -DCYGWIN -v -save-temps -Wall -W -O3 -DNDEBUG -O3 -msse4 -I/cygdrive/c/Users/Doug/Desktop/gitg2o/g2o -I/cygdrive/c/Users/Doug/Desktop/gitg2o/g2o/build-o CMakeFiles/types_sba.dir/types_sba.cpp.o -c /cygdrive/c/Users/Doug/Desktop/gitg2o/g2o/g2o/types/sba/types_sba.cpp Gives: Using built-in specs. COLLECT_GCC=/bin/c++ 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) COLLECT_GCC_OPTIONS='-Dtypes_sba_EXPORTS' '-DCYGWIN' '-v' '-save-temps' '-Wall' '-W' '-O3' '-DNDEBUG' '-O3' '-msse4' '-I/cygdrive/c/Users/Doug/Desktop/gitg2o/g2o' '-I/cygdrive/c/Users/Doug/Desktop/gitg2o/g2o/build' '-o' 'CMakeFiles/types_sba.dir/types_sba.cpp.o' '-c' '-shared-libgcc' '-mtune=generic' '-march=i686' /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1plus.exe -E -quiet -v -I/cygdrive/c/Users/Doug/Desktop/gitg2o/g2o -I/cygdrive/c/Users/Doug/Desktop/gitg2o/g2o/build -D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api -idirafter /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/lib/../../include/w32api -Dtypes_sba_EXPORTS -DCYGWIN -DNDEBUG /cygdrive/c/Users/Doug/Desktop/gitg2o/g2o/g2o/types/sba/types_sba.cpp -msse4 -mtune=generic -march=i686 -Wall -W -O3 -O3 -fpch-preprocess -o types_sba.ii ignoring nonexistent directory /usr/local/include ignoring nonexistent directory /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/include ignoring duplicate directory /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/lib/../../include/w32api #include ... search starts here: #include ... search starts here: /cygdrive/c/Users/Doug/Desktop/gitg2o/g2o /cygdrive/c/Users/Doug/Desktop/gitg2o/g2o/build /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++ /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/i686-pc-cygwin /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/backward /usr/lib/gcc/i686-pc-cygwin/4.5.3/include /usr/lib/gcc/i686-pc-cygwin/4.5.3/include-fixed /usr/include /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api End of search list. COLLECT_GCC_OPTIONS='-Dtypes_sba_EXPORTS' '-DCYGWIN' '-v' '-save-temps' '-Wall' '-W' '-O3' '-DNDEBUG' '-O3' '-msse4' '-I/cygdrive/c/Users/Doug/Desktop/gitg2o/g2o' '-I/cygdrive/c/Users/Doug/Desktop/gitg2o/g2o/build' '-o' 'CMakeFiles/types_sba.dir/types_sba.cpp.o' '-c' '-shared-libgcc' '-mtune=generic' '-march=i686' /usr/lib/gcc/i686-pc-cygwin/4.5.3/cc1plus.exe -fpreprocessed types_sba.ii -quiet -dumpbase types_sba.cpp -msse4 -mtune=generic -march=i686 -auxbase-strip CMakeFiles/types_sba.dir/types_sba.cpp.o -O3 -O3 -Wall -W -version -o types_sba.s GNU C++ (GCC) version 4.5.3 (i686-pc-cygwin) compiled by GNU C version 4.5.3, GMP version 4.3.2, MPFR version 3.0.1-p4, MPC version 0.8 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++ (GCC) version 4.5.3 (i686-pc-cygwin) compiled by GNU C version 4.5.3, GMP version 4.3.2, MPFR version 3.0.1-p4, MPC version 0.8 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 2eb50487139b9f2ceb9af473175cad84 In file included from /cygdrive/c/Users/Doug/Desktop/gitg2o/g2o/build/Eigen/Core:306:0, from /cygdrive/c/Users/Doug/Desktop/gitg2o/g2o/g2o/core/jacobian_workspace.h:30,
[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::functionvoid (std::__regex::_PatternCursor const, std::__regex::_Results)::function(std::functionvoid (std::__regex::_Patte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887 --- Comment #23 from David Edelsohn dje at gcc dot gnu.org 2012-09-16 02:36:27 UTC --- I do not see the extraneous symbols using the example in comment #22 when compiling with trunk. Also, the example G++ invocation does not enable any optimizations.
[Bug fortran/54597] New: Function can't return string without trailing spaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54597 Bug #: 54597 Summary: Function can't return string without trailing spaces Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: don...@lasg.iap.ac.cn 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.
