[Bug target/40515] SH: m2a* options not docmented.
--- Comment #2 from yoshii dot takashi at renesas dot com 2009-06-22 06:59 --- Created an attachment (id=18043) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18043&action=view) adding -m2a* options to doc/gcc/invoke.texi Mostly copied from m4a* descriptions. Even though gcc/config/sh/sh.opt describe as m2a=SH2a, and m2a-nofpu=SH2a FPU less, this patch says m2a=SH2A-FPU, and m2a-nofpu=SH2A. This comes from the manufacturer's web http://www.renesas.com/fmwk.jsp?cnt=superh_family_landing.jsp&fp=/products/mpumcu/superh_family introduces this group of CPU as "SH2A,SH2A-FPU". I don't think the difference is critical because one is the internal comment, and this one is a manual. But, somewhat confusing... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40515
[Bug target/40515] SH: m2a* options not docmented.
--- Comment #1 from kkojima at gcc dot gnu dot org 2009-06-22 05:49 --- Documentation patch welcome. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added CC||kkojima at gcc dot gnu dot ||org Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P5 Last reconfirmed|-00-00 00:00:00 |2009-06-22 05:49:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40515
[Bug middle-end/39838] [4.3/4.4/4.5 regression] unoptimal code for two simple loops
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-06-22 05:43 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-22 05:43:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39838
[Bug middle-end/40502] [4.5 Regression] crash in cp_diagnostic_starter
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-06-22 05:34 --- as witness from: In function char* strncpy(char*, const char*, size_t), inlined from void pat_read_waveheader(FILE*, WaveHeader*, int) at t.cc:7132:40: t.cc:1965:94: warning: call to char* __builtin___strncpy_chk(char*, const char*, long unsigned int, long unsigned int) will always overflow destination buffer If I add an obvious check for block being NULL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40502
[Bug middle-end/40502] [4.5 Regression] crash in cp_diagnostic_starter
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-06-22 05:33 --- This is because __artificial__ is not being treated as it should be. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet|x86_64-suse-linux | GCC target triplet||x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40502
[Bug fortran/40472] Simplification of spread intrinsic takes a long time
--- Comment #8 from pault at gcc dot gnu dot org 2009-06-22 04:48 ---
(In reply to comment #6)
> Paul, what's your point of view on replacing the linear list by the splay-tree
> ('con_by_offset' in gfc_expr)?
>
I do not know enough about splay trees to comment; however, is the problem here
not generated by the need to copy a 720 element array expression 360 times?
Unless you forego the full simplification, you will always be faced with this,
surely?
Slightly puzzled
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472
[Bug fortran/40443] Elemental procedure in genericl interface incorrectly selected in preference to specific procedure
--- Comment #8 from pault at gcc dot gnu dot org 2009-06-22 04:42 --- Subject: Bug 40443 Author: pault Date: Mon Jun 22 04:41:53 2009 New Revision: 148777 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148777 Log: 2009-06-22 Paul Thomas PR fortran/40443 * interface.c (gfc_search_interface): Hold back a match to an elementary procedure until all other possibilities are exhausted. 2009-06-22 Paul Thomas PR fortran/40443 * gfortran.dg/generic_18.f90: New test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40443
[Bug fortran/40443] Elemental procedure in genericl interface incorrectly selected in preference to specific procedure
--- Comment #7 from pault at gcc dot gnu dot org 2009-06-22 04:41 --- Subject: Bug 40443 Author: pault Date: Mon Jun 22 04:41:10 2009 New Revision: 148776 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148776 Log: 2009-06-22 Paul Thomas PR fortran/40443 * interface.c (gfc_search_interface): Hold back a match to an elementary procedure until all other possibilities are exhausted. 2009-06-22 Paul Thomas PR fortran/40443 * gfortran.dg/generic_18.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/generic_18.f90 Modified: trunk/gcc/fortran/interface.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40443
[Bug fortran/40472] Simplification of spread intrinsic takes a long time
--- Comment #7 from pault at gcc dot gnu dot org 2009-06-22 04:39 --- Subject: Bug 40472 Author: pault Date: Mon Jun 22 04:39:40 2009 New Revision: 148775 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148775 Log: 2009-06-22 Paul Thomas PR fortran/40472 * simplify.c (gfc_simplify_spread): Restrict the result size to the limit for an array constructor. 2009-06-22 Paul Thomas PR fortran/40472 * gfortran.dg/spread_size_limit.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/spread_size_limit.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472
[Bug c++/40357] [4.5 Regression] compiler hang for C++ code
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-06-22 02:18 ---
Reduced testcase:
struct XalanCProcessor
{
typedef enum {eInvalid, eXalanSourceTree, eXercesDOM} ParseOptionType;
ParseOptionType getParseOption(void);
};
typedef XalanCProcessor::ParseOptionType ParseOptionType;
ParseOptionType XalanCProcessor::getParseOption(void) {}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40357
[Bug regression/40516] New: using --with-cloog and --with-ppl without specifying a location with = causes configuration errors
results in: (all from config.log) configure:5144: checking for version 0.10 of PPL configure:5166: gcc -c -I/usr/system64/include -L/usr/system64/lib -L/usr/system64/lib64 -Iyes/include-I/usr/system64/include -L/usr/system64/lib -L/usr/system64/lib64 conftest.c >&5 configure:5172: $? = 0 configure:5265: checking for correct version of CLooG configure:5287: gcc -c -I/usr/system64/include -L/usr/system64/lib -L/usr/system64/lib64 -Iyes/include -DCLOOG_PPL_BACKEND-Iyes/include -I/usr/system64/include -L/usr/system64/lib -L/usr/system64/lib64 conftest.c >&5 configure:5293: $? = 0 LIBS='-Lyes/lib -lcloog -Lyes/lib -lppl_c -lppl -lgmpxx ' clooginc='-Iyes/include -DCLOOG_PPL_BACKEND ' clooglibs='-Lyes/lib -lcloog' As of recent with gcc 4.5.0, to use the CLOOG_PPL_BACKEND, --with-cloog and --with-ppl must be specified in the command line, making this more notable. -- Summary: using --with-cloog and --with-ppl without specifying a location with = causes configuration errors Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: xenofears at gmail dot com GCC build triplet: x86_64-w64-mingw32, i686-pc-mingw32, i686-pc-cygwin GCC host triplet: x86_64-w64-mingw32 GCC target triplet: x86_64-w64-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40516
[Bug target/40515] New: SH: m2a* options not docmented.
For SH cpu, m2a valiants has been supported since r85286. But, at least sh2a, sh2a-single, sh2a-single-only, and sh2a-nofpu found in gcc/config/sh/sh.opt are not documented in gcc/doc/invoke.texi . -- Summary: SH: m2a* options not docmented. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yoshii dot takashi at renesas dot com GCC target triplet: sh*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40515
[Bug driver/39356] assembler isn't called
--- Comment #14 from pinskia at gcc dot gnu dot org 2009-06-22 01:42 --- *** Bug 40514 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356
[Bug driver/40514] -DCLOOG_PPL_BACKEND (Windows) Native build always fails in Stage 1
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-22 01:42 --- *** This bug has been marked as a duplicate of 39356 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40514
[Bug driver/40513] Bootstrap for native build always fails in Stage 2 due to -O2 optimization
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-22 01:42 --- *** This bug has been marked as a duplicate of 39356 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40513
[Bug driver/39356] assembler isn't called
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-06-22 01:42 --- *** Bug 40513 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||xenofears at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356
[Bug driver/40514] New: -DCLOOG_PPL_BACKEND (Windows) Native build always fails in Stage 1
This bug affects 4.5.0. I can not say for certain about earlier versions. Due to the inevitable Stage 2 -O2 failure in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40513, the lines are blurred a bit looking backwards. Very similar to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40513 I have just reported. The bug's result is a very simple: $ ./gcc /home/Peter/test.c gcc.exe: CreateProcess: No such file or directory $ ./gcc /home/Peter/test.c -o test.o gcc.exe: CreateProcess: No such file or directory I have successfully cross-compiled a build using Ubuntu Linux that is unaffected, using the same libraries. The problem affects all the other drivers as well. See also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356#c0 and http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40513 -- Summary: -DCLOOG_PPL_BACKEND (Windows) Native build always fails in Stage 1 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: xenofears at gmail dot com GCC build triplet: x86_64-w64-mingw32, i686-pc-cygwin, i686-pc-mingw32 GCC host triplet: x86_64-w64-mingw32, x86_64-pc-mingw32 GCC target triplet: x86_64-w64-mingw32, x86_64-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40514
[Bug driver/40513] New: Bootstrap for native build always fails in Stage 2 due to -O2 optimization
This bug affects 4.4.0, 4.4.1, and 4.5.0. I have not tried earlier versions. The bug's result is a very simple: $ ./gcc /home/Peter/test.c -v Using built-in specs. Target: x86_64-w64-mingw32 Configured with: ../configure --host=x86_64-w64-mingw32 --target=x86_64-w64-ming w32 --enable-targets=x86_64-w64-mingw32,x86_64-pc-mingw32,i686-pc-mingw32 --pref ix=/usr/system64 --with-sysroot=/usr/system64 --enable-languages=c,c++,objc,obj- c++,fortran --disable-nls --disable-libgjc --disable-boehm-gc --disable-objc-gc --enable-fully-dynamic-strings --enable-shared --enable-shared-libgcc --enable-s hared-libstdcxx --enable-__cxa_atexit --enable-libffi --with-tune=k8 Thread model: win32 gcc version 4.5.0 20090619 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-mtune=k8' c:/system64/system64-broken/bin/../libexec/gcc/x86_64-w64-mingw32/4.5.0/cc1.exe -quiet -v -iprefix c:\system64\system64-broken\bin\../lib/gcc/x86_64-w64-mingw3 2/4.5.0/ -isysroot c:\system64\system64-broken\bin\../../system64 C:/system64/ho me/Peter/test.c -quiet -dumpbase test.c -mtune=k8 -auxbase test -version -o C:\U sers\Peter\AppData\Local\Temp\ccZz3Aej.s gcc.exe: CreateProcess: No such file or directory or $ ./gcc /home/Peter/test.c gcc.exe: CreateProcess: No such file or directory $ ./gcc /home/Peter/test.c -o test.o gcc.exe: CreateProcess: No such file or directory After much testing, building a successful compiler using Ubuntu Linux, and making it through Stage 1 building native in Cygwin or MSys, I finally discovered the cause when I tried to add -O2 to my cross-compiled Ubuntu 1-stage session identical to the prior. The problem affects all the other drivers as well. The libexec compilers are not affected - at least not in a 1-Stage Ubuntu Linux cross-compile. I hope "major" is not out-of-line, I don't know if you care about native Windows x64 support, but it is straight-out broken. There is one solution: I have succeeded by using --enable-threads=posix with Mingw-w64 ported win32-pthreads. See also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356#c0, and my about-to-post -DCLOOG_PPL_BACKEND causes the above in Stage 1. -- Summary: Bootstrap for native build always fails in Stage 2 due to -O2 optimization Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: xenofears at gmail dot com GCC build triplet: x86_64-w64-mingw32, i686-pc-cygwin, i686-pc-mingw32 GCC host triplet: x86_64-w64-mingw32, x86_64-pc-mingw32 GCC target triplet: x86_64-w64-mingw32, x86_64-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40513
[Bug driver/39356] assembler isn't called
--- Comment #12 from xenofears at gmail dot com 2009-06-22 01:11 --- (In reply to comment #10) > (In reply to comment #9) > Patch sent. See http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00914.html (I am new as an official team member of Mingw-w64, and am making a project of my own based on it. You will see it by tomorrow morning at http://www.cadforte.com for now, which I own and run in my own network. Greetings everyone.) I can confirm this works, with optimization set to -O0. Windows x64 native still fails in stage 2 with -O2, as is default for the bootstrap. I will report this as a separate bug. In addition, -DCLOOG_PPL_BACKEND fails in stage 1. I have been trying to build native x64 gcc for weeks, and you can expect other reports from me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356
[Bug tree-optimization/39974] [4.5 regression] Bogus "array subscript is below array bounds" warning in compiler generated code
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-06-22 00:43 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-22 00:43:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39974
[Bug middle-end/40095] [4.5 Regression] Revision 147342/147343 caused extra failures
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-06-22 00:25 --- Both of these have been fixed for a while now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40095
[Bug middle-end/39898] [4.5 regression] Revision 146763 caused g++.dg/tree-ssa/ehcleanup-1.C
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-22 00:20 --- This has been fixed for a while now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39898
[Bug tree-optimization/40496] [4.5 Regression] ICE in verify_stmts with -fprefetch-loop-arrays
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-06-22 00:12 --- tree_unroll_loop is causing it ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40496
[Bug middle-end/40506] ICE with -fwhole-program --combine (verify_stmts failed)
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-06-21 23:51 --- PR 39959 is the PR about the ICE on the trunk. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||39959 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40506
[Bug middle-end/40281] [4.5 Regression] -fprefetch-loop-arrays: ICE: in initialize_matrix_A, at tree-data-ref.c:1887
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-06-21 23:42 ---
Confirmed, reduced testcase:
void f(int, int);
int g(int);
extern char errortext[300];
void ParseMatrix (void)
{
char items[1000];
extern int item;
int range;
int i, j, type, cnt;
for (i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=40281
[Bug middle-end/40501] [4.5 Regression] error: invalid conversion in gimple call
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-06-21 23:33 ---
Reduced testcase:
typedef long int int64_t;
int64_t swap64(int64_t n)
{
return ( ((n & (((int64_t) 0xff) )) << 56) |
((n & (((int64_t) 0xff) << 8)) << 40) |
((n & (((int64_t) 0xff) << 16)) << 24) |
((n & (((int64_t) 0xff) << 24)) << 8) |
((n & (((int64_t) 0xff) << 32)) >> 8) |
((n & (((int64_t) 0xff) << 40)) >> 24) |
((n & (((int64_t) 0xff) << 48)) >> 40) |
((n & (((int64_t) 0xff) << 56)) >> 56) );
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40501
[Bug middle-end/40501] [4.5 Regression] error: invalid conversion in gimple call
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-06-21 23:23 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-21 23:23:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40501
[Bug objc/40507] ICE on invalid ObjC code
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-06-21 23:18 --- Yes it is a duplicate of bug 28050. *** This bug has been marked as a duplicate of 28050 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40507
[Bug objc/28050] [4.3/4.4/4.5 regression] ICE on invalid initializer
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-06-21 23:18 --- *** Bug 40507 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||debian-gcc at lists dot ||debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28050
[Bug objc/40507] ICE on invalid ObjC code
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-06-21 22:48 --- I think this is a dup of bug 28050. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40507
[Bug c/40485] definitions of __builtin_abs() and abs() function in one module not diagnosed
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-06-21 22:45 --- *** This bug has been marked as a duplicate of 32455 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40485
[Bug c/32455] [4.2/4.3/4.4/4.5 regression] ICE with modified va_list, allows declaration of __builtin_*
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-06-21 22:45 --- *** Bug 40485 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ivan dot glushkov at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32455
[Bug c++/40512] Compilation stops on valid code with ICE
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-06-21 22:09 --- Confirmed. We ICE mangling trying to mangle decltype(T()*o[0]) #1 0x082ec4c0 in write_expression (expr=0xb7fdeed4) at /home/richard/src/trunk/gcc/cp/mangle.c:2415 2415 write_expression (operand); (gdb) p expr $1 = (tree) 0xb7fdeed4 (gdb) call debug_generic_expr (expr) o[0 Breakpoint 2, internal_error ( because that ARRAY_REF has a non-array object that is referenced: (gdb) call debug_tree (expr) " no-binfo use_template=1 interface-unknown chain > used VOID file t.ii line 9 col 35 align 8 context arg-type > arg 1 constant 0>> likely this testcase should be diagnosed as invalid. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Last reconfirmed|-00-00 00:00:00 |2009-06-21 22:09:02 date|| Version|unknown |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40512
[Bug c++/40512] New: Compilation stops on valid code with ICE
compile the attached code with the -std=c++0x flag.
Environment:
System: Linux x 2.6.26-2-686 #1 SMP Thu Mar 26 01:08:11 UTC 2009 i686 GNU/Linux
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ./configure --prefix=/home/x/gcc-4.4-20090616
--enable-languages=,c,c++,
How-To-Repeat:
template
class M {
T v;
public:
T & operator[](unsigned) { return v; }
T const & operator[](unsigned) const { return v; }
template
auto mg(M o)
-> M
{
typedef M res_t;
return res_t();
}
template
auto operator*(M const & o) const
-> M
{
typedef M res_t;
return res_t();
}
};
int main(int, char *[])
{
typedef M<2, 2, int> xt;
M<3, 2, xt> hv;
M<4, 3, xt> vv;
hv.mg(vv);
}
--- Comment #1 from pooly at ural2 dot hszk dot bme dot hu 2009-06-21
21:32 ---
Fix:
Replace o[0] with oT() on line 10.
--
Summary: Compilation stops on valid code with ICE
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pooly at ural2 dot hszk dot bme dot hu
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40512
[Bug fortran/37577] Change internal array descriptor format for better syntax, C interop TR, rank 15
--- Comment #6 from tkoenig at gcc dot gnu dot org 2009-06-21 19:25 --- Subject: Bug 37577 Author: tkoenig Date: Sun Jun 21 19:24:55 2009 New Revision: 148769 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148769 Log: 2009-06-21 Thomas Koenig PR fortran/37577 Port from fortran-dev * runtime/in_pack_generic (internal_pack): Remove unnecessary test for stride == 0. * runtime/in_unpack_generic.c (internal_unpack): Likewise. * intrinsics/iso_c_binding.c (c_f_pointer_u0): Take care of stride in "shape" argument. Use array access macros for accessing array descriptors. * libgfortran.h (struct descriptor_dimension): Change stride to _stride, lbound to _lbound and ubound to _ubound. (GFC_DIMENSION_LBOUND): Use new name(s) in struct descriptor_dimension. (GFC_DIMENSION_UBOUND): Likewise. (GFC_DIMENSION_STRIDE): Likewise. (GFC_DIMENSION_EXTENT): Likewise. (GFC_DIMENSION_SET): Likewise. (GFC_DESCRIPTOR_LBOUND): Likewise. (GFC_DESCRIPTOR_UBOUND): Likewise. (GFC_DESCRIPTOR_EXTENT): Likewise. (GFC_DESCRIPTOR_STRIDE): Likewise. * io/transfer.c (transfer_array): Use array access macros. Use byte-sized strides. * intrinsics/eoshift0.c (eoshift0): Use array access macros everywhere. * m4/in_pack.m4 (internal_pack_'rtype_ccode`): Use array access macros for accessing array descriptors. * m4/in_unpack.m4 (internal_unpack_'rtype_ccode`): Likewise. * m4/matmull.m4 (matmul_'rtype_code`): Likewise. * m4/matmul.m4 (matmul_'rtype_code`): Likewise. * m4/unpack.m4 (unpack0_'rtype_code`): Likewise. (unpack1_'rtype_code`): Likewise. * m4/ifunction_logical.m4 (name`'rtype_qual`_'atype_code): Likewise. * m4/ifunction.m4 (name`'rtype_qual`_'atype_code): Use array access macros everywhere. * intrinsics/dtime.c (dtime_sub): Use array access macros for accessing array descriptors. * intrinsics/cshift0 (cshift0): Likewise. * intrinsics/etime.c: Likewise. Remove redundant calculation of rdim. * m4/cshift0.m4 (cshift0_'rtype_code`): Use array access macros for accessing array descriptors. * m4/pack.m4 (pack_'rtype_code`): Likewise. * m4/spread.m4 (spread_'rtype_code`): Likewise. (spread_scalar_'rtype_code`): Likewise. * m4/transpose.m4 (transpose_'rtype_code`): Likewise. * m4/iforeach.m4 (name`'rtype_qual`_'atype_code): Likewise. * m4/eoshift1.m4 (eoshift1): Likewise. Remove size argument, calculate within function. (eoshift1_'atype_kind`): Remove size argument from call to eoshift1. (eoshift1_'atype_kind`_char): Likewise. (eoshift1_'atype_kind`_char4): Likewise. * m4/eoshift3.m4 (eoshift3): Remove size argument, calculate within function. Use array access macros for accessing array descriptors. (eoshift3_'atype_kind`): Remove size argument from call to eoshift1. (eoshift3_'atype_kind`_char): Likewise. (eoshift3_'atype_kind`_char4): Likewise. * m4/shape.m4 (shape_'rtype_kind`): Use array access macros for accessing array descriptors. * m4/cshift1.m4 (cshift1): Remove size argument, calculate within function. Use array access macros for accessing array descriptors. (cshift1_'atype_kind`): Remove size argument from call to cshift1. (cshift1_'atype_kind`_char): Remove size argument from call to cshift1. (cshift1_'atype_kind`_char4): Remove size argument from call to cshift1. * m4/reshape.m4 (reshape_'rtype_ccode`): Use array access macros for accessing array descriptors. * m4/ifunction.m4 (name`'rtype_qual`_'atype_code): Likewise. * intrinsics/pack_generic.c (pack_internal): Use array access macros for accessing array descriptors. (pack_s_internal): Likewise. * intrinsics/transpose_generic.c (transpose_internal): Remove size argument, calculate from array descriptor. Use array access macros for accessing array descriptors. (transpose): Remove size argument from call. (transpoe_char): Likewise. (transpose_char4): Likewise. * intrinsics/move_alloc.c (move_alloc): Use array access macros for accessing array descriptors. * intrinsics/spread_generic.c (spread_internal): Remove size argument, calculate from array descriptor. Use array access macros for accessing array descriptors. (spread_internal_scalar): Likewise. (spread): Remove size argument from call to spread_internal. (spread_char): Mark argument source_length as unused. Remove size ar
[Bug fortran/39850] Too strict checking for procedures as actual argument
--- Comment #6 from janus at gcc dot gnu dot org 2009-06-21 19:16 --- Fixed with r148767. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39850
[Bug middle-end/40505] hppa: ICE: in expand_expr_addr_expr_1, at expr.c:6830
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2009-06-21 19:13 --- Subject: Re: hppa: ICE: in expand_expr_addr_expr_1, at expr.c:6830 Untested patch attached for comment. Dave --- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2009-06-21 19:13 --- Created an attachment (id=18042) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18042&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40505
[Bug fortran/39850] Too strict checking for procedures as actual argument
--- Comment #5 from janus at gcc dot gnu dot org 2009-06-21 19:05 --- Subject: Bug 39850 Author: janus Date: Sun Jun 21 19:05:35 2009 New Revision: 148767 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148767 Log: 2009-06-21 Janus Weil PR fortran/39850 * interface.c (gfc_compare_interfaces): Take care of implicit typing when checking the function attribute. Plus another bugfix. (compare_parameter): Set attr.function and attr.subroutine according to the usage of a procedure as actual argument. 2009-06-21 Janus Weil PR fortran/39850 * gfortran.dg/interface_19.f90: Add 'cleanup-modules'. * gfortran.dg/interface_20.f90: Ditto. * gfortran.dg/interface_21.f90: Ditto. * gfortran.dg/interface_22.f90: Ditto. * gfortran.dg/interface_30.f90: New. * gfortran.dg/proc_ptr_11.f90: Fix invalid test case. Added: trunk/gcc/testsuite/gfortran.dg/interface_30.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/interface_19.f90 trunk/gcc/testsuite/gfortran.dg/interface_20.f90 trunk/gcc/testsuite/gfortran.dg/interface_21.f90 trunk/gcc/testsuite/gfortran.dg/interface_22.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_11.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39850
[Bug fortran/40508] memory leak in internal write of gfortran
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-06-21 18:50 --- Confirmed. Problem narrowed down to format hashing not getting freed by Richi on IRC. I had the problem bypassed on my trunk by another patch. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-21 18:50:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40508
[Bug middle-end/40490] failure to emit resolved inline virtual function definition or IMPORT on HP-UX with -O
--- Comment #1 from danglin at gcc dot gnu dot org 2009-06-21 18:32 --- Changing to middle-end as it is responsible for determining which calls are added to the list of pending assemble externals. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|target |middle-end Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-21 18:32:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40490
[Bug fortran/40508] memory leak in internal write of gfortran
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-06-21 17:34 --- I don't doubt there is a problem. Not found with valgrind either on x86-64 linux. It's hard to debug when you can't see the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40508
[Bug fortran/40508] memory leak in internal write of gfortran
--- Comment #4 from kargl at gcc dot gnu dot org 2009-06-21 17:12 --- (In reply to comment #3) > I see no memory issues or memory growth on x85-64-linux-gnu with -m64 or > -m32. > This appears to be target specific. Checked with 4.4.1 and latest trunk. > I think there is a leak. After 3 iterations, I have REMOVE:kargl[67] ./z 1 1234567890123456789012345678901234567890123456789012 2 1234567890123456789012345678901234567890123456789012 3 1234567890123456789012345678901234567890123456789012 last pid: 17063; load averages: 0.93, 0.52, 0.34up 0+17:51:38 10:09:24 44 processes: 2 running, 42 sleeping CPU: 45.1% user, 0.0% nice, 5.6% system, 0.0% interrupt, 49.3% idle Mem: 299M Active, 438M Inact, 198M Wired, 39M Cache, 110M Buf, 11M Free Swap: 1024M Total, 60M Used, 964M Free, 5% Inuse PID USERNAMETHR PRI NICE SIZERES STATE C TIMECPU COMMAND 17063 kargl 1 1190 247M 246M CPU10 2:30 100.34% z With each iteration, the SIZE grows by about 80M. Anyone have valgrind? Last I checked, algrind did not run on FreeBSD. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40508
[Bug target/30354] -Os doesn't optimize a/CONST even if it saves size.
--- Comment #12 from vda dot linux at googlemail dot com 2009-06-21 16:48 --- Created an attachment (id=18041) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18041&action=view) Comparison of generated code with 4.4.svn.20090528 on i86 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30354
[Bug target/30354] -Os doesn't optimize a/CONST even if it saves size.
--- Comment #11 from vda dot linux at googlemail dot com 2009-06-21 16:47 --- In 32-bit code, there are indeed a few cases of code growth. Here is a full list (id_XXX are signed divides, ud_XXX are unsigned ones): - 000f T id_x_4 + 0012 T id_x_4 - 000f T id_x_8 + 0012 T id_x_8 - 000f T id_x_16 + 0012 T id_x_16 - 000f T id_x_32 + 0012 T id_x_32 - 0010 T ud_x_28 + 0015 T ud_x_28 - 0010 T ud_x_56 + 0015 T ud_x_56 - 0010 T ud_x_13952 + 0015 T ud_x_13952 They fall into two groups. Signed divisions by power-of-2 grew by 3 bytes but they are *much faster* now, and considering how often people type "x / 4" and think "this will be optimized to shift", forgetting that their x is signed, and they therefore will have divide insn (!), I see it as a good trade. Code comparison: : - 0: 8b 44 24 04 mov0x4(%esp),%eax - 4: ba 10 00 00 00 mov$0x10,%edx - 9: 89 d1 mov%edx,%ecx - b: 99 cltd - c: f7 f9 idiv %ecx - e: c3 ret + 0: 8b 54 24 04 mov0x4(%esp),%edx + 4: 89 d0 mov%edx,%eax + 6: c1 f8 1fsar$0x1f,%eax + 9: 83 e0 0fand$0xf,%eax + c: 01 d0 add%edx,%eax + e: c1 f8 04sar$0x4,%eax + 11: c3 ret The second group is just a few rare cases where "multiple by reciprocal" optimization happens to require more processing and code is 5 bytes longer: : - 0: 8b 44 24 04 mov0x4(%esp),%eax - 4: ba 38 00 00 00 mov$0x38,%edx - 9: 89 d1 mov%edx,%ecx - b: 31 d2 xor%edx,%edx - d: f7 f1 div%ecx - f: c3 ret + 0: 53 push %ebx + 1: 8b 4c 24 08 mov0x8(%esp),%ecx + 5: bb 25 49 92 24 mov$0x24924925,%ebx + a: c1 e9 03shr$0x3,%ecx + d: 89 c8 mov%ecx,%eax + f: f7 e3 mul%ebx + 11: 5b pop%ebx + 12: 89 d0 mov%edx,%eax + 14: c3 ret This is rare - only three cases in entire t.c.bz2 They are far outweighted by 474 cases where code got smaller. Most of them are saving only one byte. For example, unsigned_x / 100: : - 0: 8b 44 24 04 mov0x4(%esp),%eax - 4: ba 64 00 00 00 mov$0x64,%edx - 9: 89 d1 mov%edx,%ecx - b: 31 d2 xor%edx,%edx - d: f7 f1 div%ecx - f: c3 ret + 0: b8 1f 85 eb 51 mov$0x51eb851f,%eax + 5: f7 64 24 04 mull 0x4(%esp) + 9: 89 d0 mov%edx,%eax + b: c1 e8 05shr$0x5,%eax + e: c3 ret Some cases got shorter by 2 or 4 bytes: - 0010 T ud_x_3 + 000e T ud_x_3 - 0010 T ud_x_9 + 000e T ud_x_9 - 0010 T ud_x_67 + 000e T ud_x_67 - 0010 T ud_x_641 + 000c T ud_x_641 - 0010 T ud_x_6700417 + 000c T ud_x_6700417 For example, unsigned_x / 9: : - 0: 8b 44 24 04 mov0x4(%esp),%eax - 4: ba 09 00 00 00 mov$0x9,%edx - 9: 89 d1 mov%edx,%ecx - b: 31 d2 xor%edx,%edx - d: f7 f1 div%ecx - f: c3 ret + 0: b8 39 8e e3 38 mov$0x38e38e39,%eax + 5: f7 64 24 04 mull 0x4(%esp) + 9: 89 d0 mov%edx,%eax + b: d1 e8 shr%eax + d: c3 ret and unsigned_x / 641: : - 0: 8b 44 24 04 mov0x4(%esp),%eax - 4: ba 81 02 00 00 mov$0x281,%edx - 9: 89 d1 mov%edx,%ecx - b: 31 d2 xor%edx,%edx - d: f7 f1 div%ecx - f: c3 ret + 0: b8 81 3d 66 00 mov$0x663d81,%eax + 5: f7 64 24 04 mull 0x4(%esp) + 9: 89 d0 mov%edx,%eax + b: c3 ret I will attach t32.asm.diff now -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30354
[Bug target/30354] -Os doesn't optimize a/CONST even if it saves size.
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-06-21 16:25 --- Do we have correct size estimates on idiv with a constant argument at all? I don't see length attributes on it ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30354
[Bug target/30354] -Os doesn't optimize a/CONST even if it saves size.
--- Comment #9 from vda dot linux at googlemail dot com 2009-06-21 16:12 --- Created an attachment (id=18040) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18040&action=view) Comparison of generated code with 4.4.svn.20090528 on x86_64 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30354
[Bug target/30354] -Os doesn't optimize a/CONST even if it saves size.
--- Comment #8 from vda dot linux at googlemail dot com 2009-06-21 16:11 --- (In reply to comment #7) > It seems to make sense to bump cost of idiv a bit, given the fact that there > are register pressure implications. > > I would like to however understand what code sequences we produce that are > estimated to be long but ends up being shorter in practice. Would be possible > to try to give me some examples of constants where it is important to bump > cost > to 8? It is possible we can simply fix cost estimation in divmod expansion > instead. Attached t.c.bz2 is a good source file to experiment with. With last month's svn snapshot of gcc, I did the following: /usr/app/gcc-4.4.svn.20090528/bin/gcc -g0 -Os -fomit-frame-pointer -ffunction-sections -c t.c objdump -dr t.o >t.asm with and without the patch, and compared results. (-ffunction-sections are used merely because they make "objdump -dr" output much more suitable for diffing). Here is the diff between unpatched and patched gcc's code generated for int_x / 16: Disassembly of section .text.id_x_16: : - 0: 89 f8 mov%edi,%eax - 2: ba 10 00 00 00 mov$0x10,%edx - 7: 89 d1 mov%edx,%ecx - 9: 99 cltd - a: f7 f9 idiv %ecx - c: c3 retq + 0: 8d 47 0flea0xf(%rdi),%eax + 3: 85 ff test %edi,%edi + 5: 0f 49 c7cmovns %edi,%eax + 8: c1 f8 04sar$0x4,%eax + b: c3 retq int_x / 2: Disassembly of section .text.id_x_2: : 0: 89 f8 mov%edi,%eax - 2: ba 02 00 00 00 mov$0x2,%edx - 7: 89 d1 mov%edx,%ecx - 9: 99 cltd - a: f7 f9 idiv %ecx - c: c3 retq + 2: c1 e8 1fshr$0x1f,%eax + 5: 01 f8 add%edi,%eax + 7: d1 f8 sar%eax + 9: c3 retq As you can see, code become smaller and *much* faster (not even mul insn is used now). Here is an example of unsigned_x / 641. In this case, code size is the same, but the code is faster: Disassembly of section .text.ud_x_641: : - 0: ba 81 02 00 00 mov$0x281,%edx - 5: 89 f8 mov%edi,%eax - 7: 89 d1 mov%edx,%ecx - 9: 31 d2 xor%edx,%edx - b: f7 f1 div%ecx + 0: 89 f8 mov%edi,%eax + 2: 48 69 c0 81 3d 66 00imul $0x663d81,%rax,%rax + 9: 48 c1 e8 20 shr$0x20,%rax d: c3 retq There is not a single instance of code growth. Either newer gcc is better or maybe code growth cases are in 32-bit code only. I will attach t64.asm.diff, take a look if you want to see all changes in generated code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30354
[Bug bootstrap/40511] New: Bootstrap Failure in stage3: c++locale - Recent SVN
gmake[4]: Entering directory `/usr/home/mckelvey/software/gcc-obj/alphaev56-unknown-linux-gnu/libstdc++-v3/src' /bin/sh ../libtool --tag CXX --mode=compile /home/mckelvey/software/gcc-obj/./gcc/xgcc -shared-libgcc -B/home/mckelvey/software/gcc-obj/./gcc -nostdinc++ -L/home/mckelvey/software/gcc-obj/alphaev56-unknown-linux-gnu/libstdc++-v3/src -L/home/mckelvey/software/gcc-obj/alphaev56-unknown-linux-gnu/libstdc++-v3/src/.libs -B/usr/local/alphaev56-unknown-linux-gnu/bin/ -B/usr/local/alphaev56-unknown-linux-gnu/lib/ -isystem /usr/local/alphaev56-unknown-linux-gnu/include -isystem /usr/local/alphaev56-unknown-linux-gnu/sys-include -I/home/mckelvey/software/gcc-obj/alphaev56-unknown-linux-gnu/libstdc++-v3/include/alphaev56-unknown-linux-gnu -I/home/mckelvey/software/gcc-obj/alphaev56-unknown-linux-gnu/libstdc++-v3/include -I/home/mckelvey/software/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -mieee -c -o c++locale.lo c++locale.cc libtool: compile: /home/mckelvey/software/gcc-obj/./gcc/xgcc -shared-libgcc -B/home/mckelvey/software/gcc-obj/./gcc -nostdinc++ -L/home/mckelvey/software/gcc-obj/alphaev56-unknown-linux-gnu/libstdc++-v3/src -L/home/mckelvey/software/gcc-obj/alphaev56-unknown-linux-gnu/libstdc++-v3/src/.libs -B/usr/local/alphaev56-unknown-linux-gnu/bin/ -B/usr/local/alphaev56-unknown-linux-gnu/lib/ -isystem /usr/local/alphaev56-unknown-linux-gnu/include -isystem /usr/local/alphaev56-unknown-linux-gnu/sys-include -I/home/mckelvey/software/gcc-obj/alphaev56-unknown-linux-gnu/libstdc++-v3/include/alphaev56-unknown-linux-gnu -I/home/mckelvey/software/gcc-obj/alphaev56-unknown-linux-gnu/libstdc++-v3/include -I/home/mckelvey/software/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -mieee -c c++locale.cc -fPIC -DPIC -o .libs/c++locale.o c++locale.cc: In static member function 'static __locale_struct* std::locale::facet::_S_lc_ctype_c_locale(__locale_struct*, const char*)': c++locale.cc:158:40: error: 'LC_CTYPE_MASK' was not declared in this scope gmake[4]: *** [c++locale.lo] Error 1 gmake[4]: Leaving directory `/usr/home/mckelvey/software/gcc-obj/alphaev56-unknown-linux-gnu/libstdc++-v3/src' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/usr/home/mckelvey/software/gcc-obj/alphaev56-unknown-linux-gnu/libstdc++-v3' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/home/mckelvey/software/gcc-obj/alphaev56-unknown-linux-gnu/libstdc++-v3' gmake[1]: *** [all-target-libstdc++-v3] Error 2 gmake[1]: Leaving directory `/usr/home/mckelvey/software/gcc-obj' gmake: *** [bootstrap] Error 2 uname -a Linux alpha1 2.4.9-40 #1 Mon Sep 23 08:14:02 EDT 2002 alpha unknown g++ -v Using built-in specs. Target: alphaev56-unknown-linux-gnu Configured with: ../gcc/configure --verbose --enable-languages=c++ --disable-linux-futex --disable-nls --disable-tls Thread model: posix gcc version 4.5.0 20090423 (experimental) (GCC) BUILDING: alias CONFIGURECVS='../gcc/configure --verbose --enable-languages=c++ --disable-linux-futex --disable-nls --disable-tls 2>&1 | tee clog' alias BUILD='nice gmake CFLAGS='\'''\'' BOOT_CFLAGS='\'''\'' LIBCFLAGS='\''-g'\'' LIBCXXFLAGS='\''-g'\'' bootstrap 2>&1 | tee log' -- Summary: Bootstrap Failure in stage3: c++locale - Recent SVN Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mckelvey at maskull dot com GCC build triplet: alphaev56-unknown-linux-gnu GCC host triplet: alphaev56-unknown-linux-gnu GCC target triplet: alphaev56-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40511
[Bug c/40509] -fprofile-arcs changes behaviour
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-06-21 15:40 --- Well, for a start your asm code shows that you really shouldn't use inline asm ;) But ... asm( "movl %%ebx, %0 " : "=m" (t)); you miss an input constraint for %%ebx. But really - what are you trying to do here? The proper way for you asm is to just keep asm( "lodsl " ); asm( "mull %ebx " ); asm( "addl %ecx, %eax " ); asm( "adcl $0, %edx " ); asm( "addl (%edi), %eax " ); asm( "adcl $0, %edx " ); asm( "movl %edx, %ecx " ); asm( "stosl " ); merge it into one asm() and not do register allocation manually at all. Please consult at least the GCC manual for a start, in the section on C language extensions you will find inline assembly documentation. Or better, use an assembly file instead of inline asm if you understand assembly but not inline asm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40509
[Bug c/40509] -fprofile-arcs changes behaviour
--- Comment #6 from p dot j dot bakker at brainspark dot nl 2009-06-21 14:19 --- Subject: Re: -fprofile-arcs changes behaviour Ok. That is great (That there is not a bug in gcc :)). But I'm at a loss which extra constraints are needed. COuld you point me in the right direction? Best regards, Paul Bakker rguenth at gcc dot gnu dot org wrote: > --- Comment #5 from rguenth at gcc dot gnu dot org 2009-06-21 10:43 > --- > Your inline assembly misses required constraints for the hardregister uses. > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40509
[Bug c++/40445] g++ void f() { __builtin_unreachable(); }
-- daney at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-21 14:18:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40445
[Bug c++/40510] g++ segmentation fault in Dillo 2.1 on i586
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-21 13:15 --- Reproduced with 4.4.0, fixed on the branch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.4.1 Resolution||FIXED Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40510
[Bug fortran/40508] memory leak in internal write of gfortran
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-06-21 12:58 --- I see no memory issues or memory growth on x85-64-linux-gnu with -m64 or -m32. This appears to be target specific. Checked with 4.4.1 and latest trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40508
[Bug c++/40510] g++ segmentation fault in Dillo 2.1 on i586
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-06-21 12:23 --- Works for me (Debian sid g++-4.4.0). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40510
[Bug c++/40510] g++ segmentation fault in Dillo 2.1 on i586
--- Comment #1 from fhimpe at telenet dot be 2009-06-21 11:43 --- Created an attachment (id=18039) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18039&action=view) pre-processed source fltkui.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40510
[Bug c++/40510] New: g++ segmentation fault in Dillo 2.1 on i586
When building dillo 2.1 on Mandriva Cooker i586 with gcc 4.4.0, g++ segfaults. No specific CXXFLAGS are required to reproduce this. $ g++ fltkui.ii fltkui.cc: In member function 'void dw::fltk::ui::FltkSelectionResource::addItem(const char*, bool, bool) [with I = dw::core::ui::OptionMenuResource]': fltkui.cc:1222: instantiated from here fltkui.cc:1103: internal compiler error: Segmentation fault -- Summary: g++ segmentation fault in Dillo 2.1 on i586 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fhimpe at telenet dot be GCC build triplet: i586-mandriva-linux-gnu GCC host triplet: i586-mandriva-linux-gnu GCC target triplet: i586-mandriva-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40510
[Bug c++/40497] invalid std::next / std::prev declaration
--- Comment #16 from paolo dot carlini at oracle dot com 2009-06-21 11:08 --- This is interesting and indeed, I'm not at all sure it's a C++ bug, but I seem to remember an open PR about SFINAE vs defaults, we should check. As regards the library side, anyway, I'm against putting in place ugly workarounds, do not really make sense in this case. These next/prev are supposed to be very straightforward facilities, straightforward to implement when concepts are available. If it turns out they just make more difficult testing the other C++0x bits we already have in place we'll simply remove the code for now: let's make sure we don't ship 4.4.1 with this issue open. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||paolo dot carlini at oracle ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
[Bug fortran/40508] memory leak in internal write of gfortran
--- Comment #2 from dominiq at lps dot ens dot fr 2009-06-21 10:51 --- Confirmed on i686-apple-darwin9 revision 148750: replacing 1000 by 100, the memory usage increases by ~1.5Gb. This is a regression: I don't see the memory increase on 4.4.0, 4.4.1 r147906 (i.e., before the format caching was disabled IIRC) and 4.5.0 r147428. AFAICT this is a bug in the library: using the executable from r147428 with the library from r148750 exhibits the memory leak. -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||jb at gcc dot gnu dot org, ||jvdelisle at verizon dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40508
[Bug c/40509] -fprofile-arcs changes behaviour
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-06-21 10:43 --- Your inline assembly misses required constraints for the hardregister uses. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40509
[Bug c++/40497] invalid std::next / std::prev declaration
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-06-21 10:41 --- Bah, of course the template param isn't forwarded as a type in iterator_traits nor is it required as a type for iterator implementations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
[Bug c++/40497] invalid std::next / std::prev declaration
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-06-21 10:38
---
Testcase w/o std=c++0x:
template struct T { typedef typename I::d d; };
template I next(I __x, typename T::d __n = 1);
namespace X
{
class C { };
template void next(T) { }
}
int main()
{
X::C c;
next(c);
}
but EDG rejects this also:
t.C(1): error: class "X::C" has no member "d"
template struct T { typedef typename I::d d; };
^
detected during instantiation of class "T [with I=X::C]" at line
11
t.C(11): error: more than one instance of function template "next" matches the
argument list:
function template "void X::next(T)"
function template "I next(I, T::d)"
argument types are: (X::C)
next(c);
^
I'm not sure SFINAE applies here as the substitution T succeeds.
With the 'typename' removed in the decl for next we get
t.C(2): error: nontype "T::d [with I=I]" is not a type name
template I next(I __x, T::d __n = 1);
^
t.C(11): error: more than one instance of function template "next" matches the
argument list:
function template "void X::next(T)"
function template "I next(I, )"
argument types are: (X::C)
next(c);
^
with
template I next(typename T::d __n);
we finally get SFINAE and X::next is chosen.
The issue here seems to be that the default value for the argument somehow
gets in the way and so the 2nd argument isn't checked properly?
So an implementation workaround would be to use overloading for the
default argument case like
template I next(I __x, typename T::d __n);
template I next(I __x);
with the first arg obfuscated so that SFINAE applies,
typename iterator_traits<_InputIterator>::_InputIterator
or something like this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
[Bug middle-end/38729] long time needed in tree canonical iv
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-06-21 10:22 --- Fixed for trunk. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.3.1 4.4.1 4.5.0 |4.3.1 4.4.1 Known to work||4.5.0 Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38729
[Bug middle-end/38729] long time needed in tree canonical iv
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-06-21 10:22 --- Subject: Bug 38729 Author: rguenth Date: Sun Jun 21 10:22:08 2009 New Revision: 148761 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148761 Log: 2009-06-21 Richard Guenther PR tree-optimization/38729 * tree-ssa-loop-niter.c (find_loop_niter_by_eval): Restrict to loops with a single exit if -fno-expensive-optimizations. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-niter.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38729
[Bug c/40509] -fprofile-arcs changes behaviour
--- Comment #4 from p dot j dot bakker at brainspark dot nl 2009-06-21 10:16 --- Just tested: Also applies to gcc 4.4.0 (Debian 4.4.0-8) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40509
[Bug c/40509] -fprofile-arcs changes behaviour
--- Comment #3 from p dot j dot bakker at brainspark dot nl 2009-06-21 09:41 --- Created an attachment (id=18038) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18038&action=view) Intermediate file without -fprofile-arcs enabled -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40509
[Bug c/40509] -fprofile-arcs changes behaviour
--- Comment #2 from p dot j dot bakker at brainspark dot nl 2009-06-21 09:41 --- Created an attachment (id=18037) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18037&action=view) Intermediate file with -fprofile-arcs enabled -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40509
[Bug c/40509] -fprofile-arcs changes behaviour
--- Comment #1 from p dot j dot bakker at brainspark dot nl 2009-06-21 09:40 --- Created an attachment (id=18036) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18036&action=view) bugrep.c (The example code) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40509
[Bug c/40509] New: -fprofile-arcs changes behaviour
Architecture: i386 / i486-linux-gnu
GCC Version: 4.3.3 (Debian 4.3.3-11)
Code should perform: Multiplication of two large number arrays. It has worked
in all test cases and production environments, but suddenly fails if profiling
is enabled. More specifically the -fprofile-arcs flag triggers the behaviour.
Example multiplies 10 and 1.
Commandline for compilation of test code:
gcc bugrep.c -o bugrep
./bugrep
10 0
-and-
gcc -fprofile-arcs bugrep.c -o bugrep
./bugrep
1 0
The first answer is the right one obviously.
Small compilable snippet that triggers the behaviour.
-
#include
void func_hlp(int *s, int *d, int b)
{
int c = 0, t = 0;
asm( "movl %%ebx, %0 " : "=m" (t));
asm( "movl %0, %%esi " :: "m" (s));
asm( "movl %0, %%edi " :: "m" (d));
asm( "movl %0, %%ecx " :: "m" (c));
asm( "movl %0, %%ebx " :: "m" (b));
asm( "lodsl " );
asm( "mull %ebx " );
asm( "addl %ecx, %eax " );
asm( "adcl $0, %edx " );
asm( "addl (%edi), %eax " );
asm( "adcl $0, %edx " );
asm( "movl %edx, %ecx " );
asm( "stosl " );
asm( "movl %0, %%ebx " :: "m" (t));
asm( "movl %%ecx, %0 " : "=m" (c));
asm( "movl %%edi, %0 " : "=m" (d));
asm( "movl %%esi, %0 " : "=m" (s) ::
"eax", "ecx", "edx", "esi", "edi" );
t++;
do {
*d += c; c = ( *d < c ); d++;
}
while( c != 0 );
}
int main()
{
int a[1] = { 1 }, b[1] = { 10 }, x[2] = { 0, 0 };
func_hlp(a, x, b[0]);
printf("%d %d\n", x[0], x[1]);
return 0;
}
--
I attached both intermediate files (Both are identical!)
Result from gcc -v:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.3-11'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --with-tune=generic --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.3 (Debian 4.3.3-11)
COLLECT_GCC_OPTIONS='-v' '-fprofile-arcs' '-save-temps' '-o' 'bugrep'
'-mtune=generic'
/usr/lib/gcc/i486-linux-gnu/4.3.3/cc1 -E -quiet -v bugrep.c -mtune=generic
-fprofile-arcs -fpch-preprocess -o bugrep.i
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc/i486-linux-gnu/4.3.3/include
/usr/lib/gcc/i486-linux-gnu/4.3.3/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-fprofile-arcs' '-save-temps' '-o' 'bugrep'
'-mtune=generic'
/usr/lib/gcc/i486-linux-gnu/4.3.3/cc1 -fpreprocessed bugrep.i -quiet -dumpbase
bugrep.c -mtune=generic -auxbase bugrep -version -fprofile-arcs -o bugrep.s
GNU C (Debian 4.3.3-11) version 4.3.3 (i486-linux-gnu)
compiled by GNU C version 4.3.3, GMP version 4.2.4, MPFR version
2.4.1-p2.
warning: GMP header version 4.2.4 differs from library version 4.3.1.
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64524
Compiler executable checksum: 51094b766d4f590b9eaf6e27a27bca3f
COLLECT_GCC_OPTIONS='-v' '-fprofile-arcs' '-save-temps' '-o' 'bugrep'
'-mtune=generic'
as -V -Qy -o bugrep.o bugrep.s
GNU assembler version 2.19.1 (i486-linux-gnu) using BFD version (GNU Binutils
for Debian) 2.19.1
COMPILER_PATH=/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/4.3.3/:/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../:/lib/:/usr/lib/:/usr/lib/i486-linux-gnu/
COLLECT_GCC_OPTIONS='-v' '-fprofile-arcs' '-save-temps' '-o' 'bugrep'
'-mtune=generic'
/usr/lib/gcc/i486-linux-gnu/4.3.3/collect2 --eh-frame-hdr -m elf_i386
--hash-style=both -dynamic-linker /lib/ld-linux.so.2 -o bugrep
/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/crt1.o
/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/crti.o
/usr/lib/gcc/i486-linux-gnu/4.3.3/crtbegin.o
-L/usr/lib/gcc/i486-linux-gnu/4.3.3 -L/usr/lib/gcc/i486-linux-gnu/4.3.3
-L/usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.3.3/../../..
-L/usr/lib/i486-linu
[Bug fortran/40443] Elemental procedure in genericl interface incorrectly selected in preference to specific procedure
--- Comment #6 from pault at gcc dot gnu dot org 2009-06-21 07:42 --- This should be relatively easy to fix - I have not looked yet but I am rather sure I know what to do and where to do it. Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-06-15 11:24:02 |2009-06-21 07:42:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40443
[Bug testsuite/40475] [4.5 Regression] gcc.dg/vect/vect-nest-cycle-[12].c
--- Comment #7 from irar at il dot ibm dot com 2009-06-21 07:32 --- Fixed. -- irar at il dot ibm dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40475
[Bug testsuite/40475] [4.5 Regression] gcc.dg/vect/vect-nest-cycle-[12].c
--- Comment #6 from irar at gcc dot gnu dot org 2009-06-21 07:25 --- Subject: Bug 40475 Author: irar Date: Sun Jun 21 07:25:21 2009 New Revision: 148758 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148758 Log: PR testsuite/40475 * gcc.dg/vect/vect-nest-cycle-1.c: Fail to vectorize on targets without misalignment support. * gcc.dg/vect/vect-nest-cycle-2.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect-nest-cycle-1.c trunk/gcc/testsuite/gcc.dg/vect/vect-nest-cycle-2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40475
