[Bug fortran/54199] Superfluous diagnostic is also the name of an intrinsic for internal procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54199 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-08-09 07:52:02 UTC --- (In reply to comment #1) Maybe the second part is confusing, but a warning makes sense IMO. (For module procedures, there is a different warning, which can stay: 'fraction' declared at (1) may shadow the intrinsic of the same name. In order to call the intrinsic, explicit INTRINSIC declarations may be required.) That one would be fine for internal procedures, don't you think? Regarding a warning: Maybe it makes sense. For independent procedures, it makes a lot of sense as it is very likely to call the wrong procedure. For modules, usually the module writer has a good idea about the code (unless the module is very large) but the main problem are the module users, which inadvertently use-associating such a procedure. For internal procedures, the risk is much lower: such code is typically much smaller and it cannot be accessed from the outside. For the parent procedure, there is also no way to access the intrinsic procedure - the INTRINSIC only allows the access for other internal procedures. Thus, the importance of the warning is single proc module proc internal proc (and the question where one stops warning with -Wall). In any case, I concur that for internal procedures the warning wording for module procedures is much better than the current one, whose second part is plainly wrong.
[Bug tree-optimization/54200] copyrename generates wrong debuginfo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54200 --- Comment #5 from rguenther at suse dot de rguenther at suse dot de 2012-08-09 08:05:51 UTC --- On Wed, 8 Aug 2012, pinskia at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54200 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2012-08-08 15:31:09 UTC --- The other thing which copyrename helps is register allocation as it allows out of ssa to coalesce some ssa names which could not do before. Yes, though that's a matter of adjusting what coalescing can coalesce (which is only limited to the sets it computes conflicts for)
[Bug c++/52748] [C++11] N3276 changes to decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748 --- Comment #1 from Johan Lundberg lundberj at gmail dot com 2012-08-09 08:08:46 UTC --- confirmed... I agree with this. Among other things it's important for boost/C++11 interop.
[Bug lto/54206] build in source dir breaks lto plugin detection
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54206 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-09 CC||steven at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Steven Bosscher steven at gcc dot gnu.org 2012-08-09 08:31:14 UTC --- Confirmed. But from http://gcc.gnu.org/install/configure.html: First, we *highly* recommend that GCC be built into a separate directory from the sources which does not reside within the source tree. This is how we generally build GCC; building where srcdir == objdir should still work, but doesn't get extensive testing; building where objdir is a subdirectory of srcdir is unsupported. So WONTFIX is tempting...
[Bug middle-end/54201] XMM constant duplicated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54201 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-08-09 09:49:49 UTC --- Mine for now.
[Bug bootstrap/53902] make install fails on SunOS 5.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53902 T.J. Yang tjyang2001 at gmail dot com changed: What|Removed |Added CC||tjyang2001 at gmail dot com --- Comment #1 from T.J. Yang tjyang2001 at gmail dot com 2012-08-09 10:16:22 UTC --- I got same error message on a Solaris 11 X86 VMWare session also.
[Bug middle-end/54201] XMM constant duplicated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54201 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-08-09 10:21:57 UTC --- Created attachment 27965 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27965 idea Uh, the constant pool is filled via force_const_mem and I thought about beefing up the wrong routines ... unfortunately we don't have a native_encode_expr for RTXen. See attachment for the idea which also would allow sharing parts of constants (if a larger one happens to be output first).
[Bug c++/54155] Newly compiled GCC 4.4.4 on Solaris sparc gives problem with -m32/-m64 flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54155 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-08-09 10:45:20 UTC --- --- Comment #7 from damz dshanke at gmail dot com 2012-08-08 17:40:37 UTC --- How I wish that the supportability matrix was published. I hope you understand that this is completely unfeasible: I'm currently testing gcc 4.6/4.7/4.8 on Solaris 8/9/10/11, both sparc and x86. Adding older gcc releases (which are no longer maintained anyway) and more than one (the current) binutils release to that testing simply cannot be done in reasonable time, with finite amounts of diskspace, and man power to analyse the results. Did I miss to see a document saying that ld 2.21 will not be supported by GCC 4.4.4 and below? :( No, but in general (which is not yet true for gcc 4.4) I try to list the latest binutils version known to work with that version of gcc. With newer binutils releases, you're on your own. They may well work, but no guarantees. I was hoping that backward compatibility was mostly retained! Agreed, but as I said when I found that gcc 4.4 doesn't work with gld 2.21, I immediately backported the patch to that release branch. Rainer
[Bug bootstrap/53902] make install fails on SunOS 5.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53902 --- Comment #2 from T.J. Yang tjyang2001 at gmail dot com 2012-08-09 10:58:54 UTC --- Found following URLs could be helpful to resolve the issue. http://echelog.com/logs/browse/oi-dev/1315000800. https://github.com/richlowe/gcc/commit/610511a2a04185795a2e0d08ff25369126719346
[Bug c++/54207] New: ICE in build_noexcept_spec when bool is #defined/typedef'd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54207
Bug #: 54207
Summary: ICE in build_noexcept_spec when bool is
#defined/typedef'd
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: andrew...@gmail.com
This ICE occurs under unique/odd but reproducible conditions. The key
components of the environment for this bug appear to be:
1. 'bool' is typedef'd to a new type which is then #define'd over the existing
'bool' type (this is the case in the common.h head from the ldns package,
http://www.nlnetlabs.nl/projects/ldns/).
2. A user-defined class inherits from a templated base class, like
std::vectorstring.
3. This same class calls a noexcept method on a vector member (which appears to
trigger the build_noexcept_spec function).
This bug is reproducible with the following code on gcc-4.7. It compiles
without error on gcc-4.6:
--
typedef bool _Bool;
# define bool _Bool
#include vector
#include iostream
#include cstring
using namespace std;
class Test : public vectorstring {
public:
Test (Test that) {
arr = std::move(that.arr);
}
private:
std::vectorint* arr;
};
[Bug bootstrap/53902] make install fails on SunOS 5.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53902 --- Comment #3 from T.J. Yang tjyang2001 at gmail dot com 2012-08-09 11:05:55 UTC --- Also at http://gcc.gnu.org/viewcvs/trunk/gcc/configure.ac?revision=189803view=markup, around line 2461. the previous fix is included in gcc trunk.
[Bug bootstrap/53902] make install fails on SunOS 5.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53902
--- Comment #4 from T.J. Yang tjyang2001 at gmail dot com 2012-08-09 11:11:22
UTC ---
I tried the gcc trunk src and named it as 4.7.2. but I am getting same error
message.
tjyang@b-solaris11-amd64:~/build/gcc-4.7.2-objdir/i386-pc-solaris2.11/libitm$
pwd
/home/tjyang/build/gcc-4.7.2-objdir/i386-pc-solaris2.11/libitm
tjyang@b-solaris11-amd64:~/build/gcc-4.7.2-objdir/i386-pc-solaris2.11/libitm$
make
make all-recursive
make[1]: Entering directory
`/home/tjyang/build/gcc-4.7.2-objdir/i386-pc-solaris2.11/libitm'
Making all in testsuite
make[2]: Entering directory
`/home/tjyang/build/gcc-4.7.2-objdir/i386-pc-solaris2.11/libitm/testsuite'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory
`/home/tjyang/build/gcc-4.7.2-objdir/i386-pc-solaris2.11/libitm/testsuite'
make[2]: Entering directory
`/home/tjyang/build/gcc-4.7.2-objdir/i386-pc-solaris2.11/libitm'
make DO=all multi-do # make
make[3]: Entering directory
`/home/tjyang/build/gcc-4.7.2-objdir/i386-pc-solaris2.11/libitm'
if [ -z amd64 ]; then \
true; \
else \
rootpre=`${PWDCMD-pwd}`/; export rootpre; \
srcrootpre=`cd /home/tjyang/build/gcc-4.7.2/libitm; ${PWDCMD-pwd}`/;
export srcrootpre; \
lib=`echo ${rootpre} | sed -e 's,^.*/\([^/][^/]*\)/$,\1,'`; \
compiler=/home/tjyang/build/gcc-4.7.2-objdir/./gcc/xgcc
-B/home/tjyang/build/gcc-4.7.2-objdir/./gcc/
-B/opt/moto/gcc472/i386-pc-solaris2.11/bin/
-B/opt/moto/gcc472/i386-pc-solaris2.11/lib/ -isystem
/opt/moto/gcc472/i386-pc-solaris2.11/include -isystem
/opt/moto/gcc472/i386-pc-solaris2.11/sys-include ; \
for i in `${compiler} --print-multi-lib 2/dev/null`; do \
dir=`echo $i | sed -e 's/;.*$//'`; \
if [ ${dir} = . ]; then \
true; \
else \
if [ -d ../${dir}/${lib} ]; then \
flags=`echo $i | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`; \
if (cd ../${dir}/${lib}; make \
CFLAGS=-g -O2 -pthread ${flags} \
CCASFLAGS=-g -O2 ${flags} \
FCFLAGS= ${flags} \
FFLAGS= ${flags} \
ADAFLAGS= ${flags} \
prefix=/opt/moto/gcc472 \
exec_prefix=/opt/moto/gcc472 \
GCJFLAGS= ${flags} \
GOCFLAGS= ${flags} \
CXXFLAGS=-g -O2 ${flags} \
LIBCFLAGS= ${flags} \
LIBCXXFLAGS= ${flags} \
LDFLAGS= ${flags} \
MULTIFLAGS=${flags} \
DESTDIR= \
INSTALL=/usr/gnu/bin/install -c \
INSTALL_DATA=/usr/gnu/bin/install -c -m 644 \
INSTALL_PROGRAM=/usr/gnu/bin/install -c \
INSTALL_SCRIPT=/usr/gnu/bin/install -c \
all); then \
true; \
else \
exit 1; \
fi; \
else true; \
fi; \
fi; \
done; \
fi
make[4]: Entering directory
`/home/tjyang/build/gcc-4.7.2-objdir/i386-pc-solaris2.11/amd64/libitm'
make all-recursive
make[5]: Entering directory
`/home/tjyang/build/gcc-4.7.2-objdir/i386-pc-solaris2.11/amd64/libitm'
Making all in testsuite
make[6]: Entering directory
`/home/tjyang/build/gcc-4.7.2-objdir/i386-pc-solaris2.11/amd64/libitm/testsuite'
make[6]: Nothing to be done for `all'.
make[6]: Leaving directory
`/home/tjyang/build/gcc-4.7.2-objdir/i386-pc-solaris2.11/amd64/libitm/testsuite'
make[6]: Entering directory
`/home/tjyang/build/gcc-4.7.2-objdir/i386-pc-solaris2.11/amd64/libitm'
/opt/TWWfsw/sbutils13/lib/aux/bash/bin/bash ./libtool --tag=CC --mode=link
/home/tjyang/build/gcc-4.7.2-objdir/./gcc/xgcc
-B/home/tjyang/build/gcc-4.7.2-objdir/./gcc/
-B/opt/moto/gcc472/i386-pc-solaris2.11/bin/
-B/opt/moto/gcc472/i386-pc-solaris2.11/lib/ -isystem
/opt/moto/gcc472/i386-pc-solaris2.11/include -isystem
/opt/moto/gcc472/i386-pc-solaris2.11/sys-include -m64 -Wall -Werror
-Wc,-pthread -g -O2 -pthread -m64
-Wl,-M,/home/tjyang/build/gcc-4.7.2/libitm/clearcap.map -m64 -o libitm.la
-version-info 1:0:0 -Wl,-M,libitm.map-sun -rpath /opt/moto/gcc472/lib/amd64
aatree.lo alloc.lo alloc_c.lo alloc_cpp.lo barrier.lo beginend.lo clone.lo
eh_cpp.lo local.lo query.lo retry.lo rwlock.lo useraction.lo util.lo sjlj.lo
tls.lo method-serial.lo method-gl.lo method-ml.lo x86_sse.lo x86_avx.lo
libtool: link: /home/tjyang/build/gcc-4.7.2-objdir/./gcc/xgcc
-B/home/tjyang/build/gcc-4.7.2-objdir/./gcc/
-B/opt/moto/gcc472/i386-pc-solaris2.11/bin/
-B/opt/moto/gcc472/i386-pc-solaris2.11/lib/ -isystem
[Bug c++/54207] ICE in build_noexcept_spec when bool is #defined/typedef'd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54207 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-09 11:39:10 UTC --- 4.7.1 gets an ICE too, but it works on trunk. As it's undefined behaviour (bool is a keyword) and it already works on trunk it might not be worth changing anything.
[Bug c++/54155] Newly compiled GCC 4.4.4 on Solaris sparc gives problem with -m32/-m64 flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54155 --- Comment #9 from damz dshanke at gmail dot com 2012-08-09 12:02:42 UTC --- (In reply to comment #8) --- Comment #7 from damz dshanke at gmail dot com 2012-08-08 17:40:37 UTC --- How I wish that the supportability matrix was published. I hope you understand that this is completely unfeasible: I'm currently testing gcc 4.6/4.7/4.8 on Solaris 8/9/10/11, both sparc and x86. Adding older gcc releases (which are no longer maintained anyway) and more than one (the current) binutils release to that testing simply cannot be done in reasonable time, with finite amounts of diskspace, and man power to analyse the results. Did I miss to see a document saying that ld 2.21 will not be supported by GCC 4.4.4 and below? :( No, but in general (which is not yet true for gcc 4.4) I try to list the latest binutils version known to work with that version of gcc. With newer binutils releases, you're on your own. They may well work, but no guarantees. I was hoping that backward compatibility was mostly retained! Agreed, but as I said when I found that gcc 4.4 doesn't work with gld 2.21, I immediately backported the patch to that release branch. Rainer Thank you Rainer. I really appreciate your transparent replies. Cheers! signing off damz
[Bug fortran/54199] Superfluous diagnostic is also the name of an intrinsic for internal procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54199 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-08-09 12:06:36 UTC --- Author: burnus Date: Thu Aug 9 12:06:31 2012 New Revision: 190251 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190251 Log: 2012-08-09 Tobias Burnus bur...@net-b.de PR fortran/54199 * intrinsic.c (gfc_warn_intrinsic_shadow): Better warning for internal procedures. 2012-08-09 Tobias Burnus bur...@net-b.de PR fortran/54199 * gfortran.dg/intrinsic_shadow_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/intrinsic_shadow_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/54199] Superfluous diagnostic is also the name of an intrinsic for internal procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54199 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-08-09 12:06:36 UTC --- Author: burnus Date: Thu Aug 9 12:06:31 2012 New Revision: 190251 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190251 Log: 2012-08-09 Tobias Burnus bur...@net-b.de PR fortran/54199 * intrinsic.c (gfc_warn_intrinsic_shadow): Better warning for internal procedures. 2012-08-09 Tobias Burnus bur...@net-b.de PR fortran/54199 * gfortran.dg/intrinsic_shadow_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/intrinsic_shadow_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.c trunk/gcc/testsuite/ChangeLog --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-08-09 12:06:57 UTC --- FIXED on the 4.8 trunk.
[Bug fortran/54199] Superfluous diagnostic is also the name of an intrinsic for internal procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54199 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-08-09 12:06:57 UTC --- FIXED on the 4.8 trunk.
[Bug lto/54206] build in source dir breaks lto plugin detection
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54206 --- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2012-08-09 12:39:14 UTC --- I didn't do it, but I had to debug a user's gcc config who did it. WONTFIX would be wrong, if you really don't support it error out in configure please instead of silent breakage (glibc does that). But fixing it would be better I think.
[Bug tree-optimization/54027] [4.8 Regression] possible mis-optimization of signed left shift in c89 mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54027
Markus Trippelsdorf markus at trippelsdorf dot de changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de
--- Comment #4 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-08-09 13:31:22 UTC ---
FYI this also turns glibc's __ieee754_fmodf into an endless loop:
From sysdeps/ieee754/flt-32/e_fmodf.c:
float
__ieee754_fmodf (float x, float y)
{
int32_t n,hx,hy,hz,ix,iy,sx,i;
GET_FLOAT_WORD(hx,x);
GET_FLOAT_WORD(hy,y);
sx = hx0x8000; /* sign of x */
hx ^=sx;/* |x| */
hy = 0x7fff; /* |y| */
/* purge off exception values */
if(hy==0||(hx=0x7f80)||/* y=0,or x not finite */
(hy0x7f80)) /* or y is NaN */
return (x*y)/(x*y);
if(hxhy) return x; /* |x||y| return x */
if(hx==hy)
return Zero[(u_int32_t)sx31]; /* |x|=|y| return x*0*/
/* determine ix = ilogb(x) */
if(hx0x0080) { /* subnormal x */
for (ix = -126,i=(hx8); i0; i=1) ix -=1;
} //^ endless loop
Disassembly of section .text:
__fmodf_finite:
0: 66 0f 7e c0 movd %xmm0,%eax
4: 89 c7 mov%eax,%edi
6: 81 e7 00 00 00 80 and$0x8000,%edi
c: 66 41 0f 7e c8 movd %xmm1,%r8d
11: 31 f8 xor%edi,%eax
13: 44 89 c6mov%r8d,%esi
16: 81 e6 ff ff ff 7f and$0x7fff,%esi
1c: 3d ff ff 7f 7f cmp$0x7f7f,%eax
21: 7f 2d jg 50 __fmodf_finite+0x50
23: 85 f6 test %esi,%esi
25: 74 29 je 50 __fmodf_finite+0x50
27: 81 fe 00 00 80 7f cmp$0x7f80,%esi
2d: 7f 21 jg 50 __fmodf_finite+0x50
2f: 39 f0 cmp%esi,%eax
31: 7c 6d jl a0 __fmodf_finite+0xa0
33: 74 73 je a8 __fmodf_finite+0xa8
35: 3d ff ff 7f 00 cmp$0x7f,%eax
3a: 89 c2 mov%eax,%edx
3c: 7f 7a jg b8 __fmodf_finite+0xb8
3e: c1 e2 08shl$0x8,%edx
41: 85 d2 test %edx,%edx
43: 0f 8e 2a 01 00 00 jle173 __fmodf_finite+0x173
49: eb fe jmp49 __fmodf_finite+0x49
[Bug rtl-optimization/53701] ICE on ia64 (when building Allegro 4.4) in sel-sched
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53701 --- Comment #8 from Andrey Belevantsev abel at gcc dot gnu.org 2012-08-09 14:08:38 UTC --- Author: abel Date: Thu Aug 9 14:08:31 2012 New Revision: 190253 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190253 Log: PR rtl-optimization/53701 * sel-sched.c (vinsn_vec_has_expr_p): Clarify function comment. Process not only expr's vinsns but all old vinsns from expr's history of changes. (update_and_record_unavailable_insns): Clarify comment. * gcc.dg/pr53701.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr53701.c Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/54157] [x32] -maddress-mode=long failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54157 --- Comment #7 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-08-09 15:33:36 UTC --- Author: hjl Date: Thu Aug 9 15:33:28 2012 New Revision: 190256 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190256 Log: Don't return identity for CONST or symbolic reference gcc/ 2012-08-09 H.J. Lu hongjiu...@intel.com Backport from mainline 2012-08-08 Richard Sandiford rdsandif...@googlemail.com H.J. Lu hongjiu...@intel.com PR rtl-optimization/54157 * combine.c (gen_lowpart_for_combine): Don't return identity for CONST or symbolic reference. gcc/testsuite/ 2012-08-09 H.J. Lu hongjiu...@intel.com Backport from mainline 2012-08-08 H.J. Lu hongjiu...@intel.com PR rtl-optimization/54157 * gcc.target/i386/pr54157.c: New file. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/pr54157.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/combine.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug fortran/54208] New: compilation error for ubound construct in PARAMETER statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54208 Bug #: 54208 Summary: compilation error for ubound construct in PARAMETER statements Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: carlos.a.c...@nasa.gov The following reproducer: program testit integer, parameter :: n=2 integer, dimension(1-min(n,2)/2:n) :: arr integer, parameter :: i=ubound(arr,1) write(6,*) i end program testit fails to compile: gfortran testit.F90 testit.F90:4.33: integer, parameter :: i=ubound(arr,1) 1 Error: Array 'arr' at (1) is a variable, which does not reduce to a constant expression This error causes a problem when compiling GISS's climate model (modelE), which has similar constructs, but it is not a problem with other compilers (e.g. intel 12.1) Additional information: --- gfortran --version GNU Fortran (GCC) 4.8.0 20120401 (experimental) Copyright (C) 2012 Free Software Foundation, Inc. gcc -v -save-temps testit.F90 Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/other/SLES11/gcc/4.8-20120401/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /gpfsm/dnbsrc/other/GCC/SLES11/4.8-20120401/gcc-4.8-20120401/configure --prefix=/usr/local/other/SLES11/gcc/4.8-20120401 CC=gcc --enable-languages=all Thread model: posix gcc version 4.8.0 20120401 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=x86-64' /usr/local/other/SLES11/gcc/4.8-20120401/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/f951 testit.F90 -cpp=testit.f90 -quiet -v testit.F90 -quiet -dumpbase testit.F90 -mtune=generic -march=x86-64 -auxbase testit -version -fintrinsic-modules-path /usr/local/other/SLES11/gcc/4.8-20120401/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/finclude -o testit.s GNU Fortran (GCC) version 4.8.0 20120401 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.8.0 20120401 (experimental), GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory /usr/local/other/SLES11/gcc/4.8-20120401/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/local/other/SLES11/gcc/4.8-20120401/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/finclude /usr/local/other/SLES11/gcc/4.8-20120401/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include /usr/local/include /usr/local/other/SLES11/gcc/4.8-20120401/include /usr/local/other/SLES11/gcc/4.8-20120401/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include-fixed /usr/include End of search list.
[Bug target/50751] SH Target: Displacement addressing does not work for QImode and HImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751 --- Comment #30 from Oleg Endo olegendo at gcc dot gnu.org 2012-08-09 15:51:25 UTC --- Author: olegendo Date: Thu Aug 9 15:51:20 2012 New Revision: 190257 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190257 Log: PR target/50751 * config/sh/sh.md (*extendqisi2_compact_reg, *extendhisi2_compact_reg): Use arith_reg_operand predicate instead of register_operand. * config/sh/predicates.md (movsrc_no_disp_mem_operand): Accept only mem, simplify. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/predicates.md trunk/gcc/config/sh/sh.md
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #46 from Oleg Endo olegendo at gcc dot gnu.org 2012-08-09 15:55:23 UTC --- Author: olegendo Date: Thu Aug 9 15:55:18 2012 New Revision: 190258 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190258 Log: PR target/51244 * config/sh/sh.md: Add negc extu sequence peephole. (movrt, movnegt, movrt_negc, nott): Use t_reg_operand predicate. (*movrt_negc): New insn. * config/sh/sync.md (atomic_test_and_set): Pass gen_t_reg_rtx to gen_movnegt. * config/sh/sh.c (expand_cbranchsi4, sh_emit_scc_to_t, sh_emit_compare_and_branch, sh_emit_compare_and_set): Use get_t_reg_rtx. (sh_expand_t_scc): Pass gen_t_reg_rtx to gen_movnegt. PR target/51244 * gcc.target/sh/pr51244-5: New. * gcc.target/sh/pr51244-6: New. Added: trunk/gcc/testsuite/gcc.target/sh/pr51244-5.c trunk/gcc/testsuite/gcc.target/sh/pr51244-6.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.md trunk/gcc/config/sh/sync.md trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/54209] New: [4.8 Regression] Failed to build gcc for Android/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54209 Bug #: 54209 Summary: [4.8 Regression] Failed to build gcc for Android/x86 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: areg.melikadam...@gmail.com, chaoyin...@gcc.gnu.org Revision 190242 failed to build for i686-pc-linux-android. I got /export/gnu/import/git/gcc/libgcc/unwind-dw2-fde-dip.c:75:18: fatal error: link.h: No such file or directory #include link.h It is caused by revision 186788: http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00740.html due to #if defined(USE_PT_GNU_EH_FRAME) #include link.h but Bionic/x86 doesn't have link.h.
[Bug bootstrap/54209] [4.8 Regression] Failed to build gcc for Android/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54209 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug target/39423] [4.6/4.7/4.8 Regression] [SH] performance regression: lost mov @(disp,Rn)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39423 --- Comment #23 from Oleg Endo olegendo at gcc dot gnu.org 2012-08-09 15:58:08 UTC --- Author: olegendo Date: Thu Aug 9 15:58:04 2012 New Revision: 190259 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190259 Log: PR target/39423 * config/sh/predicates.md (mem_index_disp_operand): New predicate. * config/sh/sh.md (*movsi_index_disp): Rewrite insns to use the new mem_index_disp_operand predicate. PR target/39423 * gcc.target/sh/pr39423-1.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/pr39423-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/predicates.md trunk/gcc/config/sh/sh.md trunk/gcc/testsuite/ChangeLog
[Bug fortran/54208] compilation error for ubound construct in PARAMETER statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54208 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org 2012-08-09 16:32:07 UTC --- (In reply to comment #0) The following reproducer: program testit integer, parameter :: n=2 integer, dimension(1-min(n,2)/2:n) :: arr integer, parameter :: i=ubound(arr,1) write(6,*) i end program testit fails to compile: gfortran testit.F90 testit.F90:4.33: integer, parameter :: i=ubound(arr,1) 1 Error: Array 'arr' at (1) is a variable, which does not reduce to a constant expression I believe that this may be a duplicate of another bug report, but don't have time to check. This problem is present in all versions of gfortran from at least 4.3.6 onward. Oddly, if one tries 4.2.5, the code compiles. A workaround (and yes I know changing a large code base may be a PITA) is program testit integer, parameter :: n=2, m=1-min(n,2)/2 integer, dimension(m:n) :: arr integer, parameter :: i=ubound(arr,1) write(6,*) i end program testit
[Bug bootstrap/54209] [4.8 Regression] Failed to build gcc for Android/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54209 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-08/msg00548.htm ||l --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-08-09 16:41:09 UTC --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00548.html
[Bug target/39423] [4.6/4.7/4.8 Regression] [SH] performance regression: lost mov @(disp,Rn)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39423 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added CC||kkojima at gcc dot gnu.org --- Comment #24 from Oleg Endo olegendo at gcc dot gnu.org 2012-08-09 16:55:19 UTC --- Christian, do you have anything to add regarding this matter? I'm not sure whether this should be back ported to 4.6.x or 4.7.x or not. Kaz, what do you think?
[Bug driver/54210] New: gcc unable to detect -mprfchw flag in bulldozer machines
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54210 Bug #: 54210 Summary: gcc unable to detect -mprfchw flag in bulldozer machines Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: ganesh.gopalasubraman...@amd.com In a bulldozer machine, GCC is unable to detect the prfchw flag (Bulldozer has prefetchw support). gcc -### -v -march=native /usr/include/stdlib.h returns ./cc1 -quiet -v /usr/include/stdlib.h -march=bdver1 -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mabm -mlwp -mno-fma -mfma4 -mxop -mno-bmi -mno-bmi2 -mno-tbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=bdver1 -quiet -dumpbase stdlib.h -auxbase stdlib -version -o /tmp/ccdFQZD3.s --output-pch=/usr/include/stdlib.h.gch Further analysis shows that in gcc/config/i386/driver-i386.c, cpuid function number 7 is called instead of calling cpuid function 0x8001 for getting the prefetchw flag.
[Bug middle-end/54211] New: [4.8 Regression] ICE: verify_gimple failed building freetype with -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54211 Bug #: 54211 Summary: [4.8 Regression] ICE: verify_gimple failed building freetype with -Os Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: rmansfi...@qnx.com CC: wschm...@linux.vnet.ibm.com Host: x86_64-unknown-linux-gnu Target: x86_64-unknown-linux-gnu Build: x86_64-unknown-linux-gnu Created attachment 27966 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27966 preprocessed src After rev190220, freetype fails to build with -Os. Seen on mips, ppc x86 and x86_64. Reduced testcase: /home/ryan/ice.i: In function ‘tt_face_load_sbit_image’: /home/ryan/ice.i:365:1: error: type mismatch in pointer plus expression tt_face_load_sbit_image (TT_Face face, FT_ULong strike_index, ^ sizetype unsigned long sizetype D.2244_30 = D.2241_17 + slsr.98_48; /home/ryan/ice.i:365:1: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug bootstrap/54209] [4.8 Regression] Failed to build gcc for Android/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54209
--- Comment #2 from chaoyingfu at gcc dot gnu.org chaoyingfu at gcc dot
gnu.org 2012-08-09 17:23:40 UTC ---
MIPS provides a version of link.h in Android NDK as follows:
Ex:
From android-ndk-r8b/platforms/android-9/arch-mips/usr/include# cat link.h
/*
For building unwind-dw2-fde-glibc.c for MIPS frame unwinding,
we need to have link.h that defines struct dl_phdr_info,
ELFW(type), and dl_iterate_phdr().
*/
#include sys/types.h
#include elf.h
struct dl_phdr_info
{
Elf32_Addr dlpi_addr;
const char *dlpi_name;
const Elf32_Phdr *dlpi_phdr;
Elf32_Half dlpi_phnum;
};
#if _MIPS_SZPTR == 32
#define ElfW(type) Elf32_##type
#elif _MIPS_SZPTR == 64
#define ElfW(type) Elf64_##type
#endif
int
dl_iterate_phdr(int (*cb)(struct dl_phdr_info *info, size_t size, void *data),
void *data);
For x86, you can create link.h as well. Or we can guard this define with
MIPS targets.
Ex:
#if !defined(inhibit_libc) defined(HAVE_LD_EH_FRAME_HDR) \
defined(__BIONIC__) defined(__mips__)
# define USE_PT_GNU_EH_FRAME
#endif
Thanks!
[Bug middle-end/54211] [4.8 Regression] ICE: verify_gimple failed building freetype with -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54211
Markus Trippelsdorf markus at trippelsdorf dot de changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de
--- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-08-09 17:38:46 UTC ---
Further reduced:
int a, b;
unsigned char e;
void fn1 ()
{
unsigned char *c=0;
for (;; a++)
{
unsigned char d = *(c + b);
for (; ed; c++)
goto Found_Top;
}
Found_Top:
if (0)
goto Empty_Bitmap;
for (;; a++)
{
unsigned char *e = c + b;
for (; c e; c++)
goto Found_Bottom;
c -= b;
}
Found_Bottom:
Empty_Bitmap:
;
}
[Bug driver/54210] gcc unable to detect -mprfchw flag in bulldozer machines
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54210 --- Comment #1 from GGanesh Ganesh.Gopalasubramanian at amd dot com 2012-08-09 18:04:39 UTC --- Calling the cpuid function 0x8001 does it for bulldozer architecture. Is it OK for upstream? Index: gcc/config/i386/driver-i386.c === --- gcc/config/i386/driver-i386.c (revision 189996) +++ gcc/config/i386/driver-i386.c (working copy) @@ -467,7 +467,6 @@ has_bmi2 = ebx bit_BMI2; has_fsgsbase = ebx bit_FSGSBASE; has_rdseed = ebx bit_RDSEED; - has_prfchw = ecx bit_PRFCHW; } /* Check cpuid level of extended features. */ @@ -491,6 +490,7 @@ has_longmode = edx bit_LM; has_3dnowp = edx bit_3DNOWP; has_3dnow = edx bit_3DNOW; + has_prfchw = ecx bit_PRFCHW; } if (!arch)
[Bug bootstrap/54209] [4.8 Regression] Failed to build gcc for Android/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54209
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC||pavel.v.chupin at gmail dot
||com
--- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-08-09 18:40:54
UTC ---
(In reply to comment #2)
MIPS provides a version of link.h in Android NDK as follows:
Ex:
From android-ndk-r8b/platforms/android-9/arch-mips/usr/include# cat link.h
/*
For building unwind-dw2-fde-glibc.c for MIPS frame unwinding,
we need to have link.h that defines struct dl_phdr_info,
ELFW(type), and dl_iterate_phdr().
*/
#include sys/types.h
#include elf.h
struct dl_phdr_info
{
Elf32_Addr dlpi_addr;
const char *dlpi_name;
const Elf32_Phdr *dlpi_phdr;
Elf32_Half dlpi_phnum;
};
#if _MIPS_SZPTR == 32
#define ElfW(type) Elf32_##type
#elif _MIPS_SZPTR == 64
#define ElfW(type) Elf64_##type
#endif
int
dl_iterate_phdr(int (*cb)(struct dl_phdr_info *info, size_t size, void *data),
void *data);
For x86, you can create link.h as well. Or we can guard this define with
MIPS targets.
Why isn't link.h in AOSP Bionic C library?
[Bug bootstrap/54209] [4.8 Regression] Failed to build gcc for Android/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54209
--- Comment #4 from chaoyingfu at gcc dot gnu.org chaoyingfu at gcc dot
gnu.org 2012-08-09 18:45:41 UTC ---
(In reply to comment #3)
(In reply to comment #2)
MIPS provides a version of link.h in Android NDK as follows:
Ex:
From android-ndk-r8b/platforms/android-9/arch-mips/usr/include# cat link.h
/*
For building unwind-dw2-fde-glibc.c for MIPS frame unwinding,
we need to have link.h that defines struct dl_phdr_info,
ELFW(type), and dl_iterate_phdr().
*/
#include sys/types.h
#include elf.h
struct dl_phdr_info
{
Elf32_Addr dlpi_addr;
const char *dlpi_name;
const Elf32_Phdr *dlpi_phdr;
Elf32_Half dlpi_phnum;
};
#if _MIPS_SZPTR == 32
#define ElfW(type) Elf32_##type
#elif _MIPS_SZPTR == 64
#define ElfW(type) Elf64_##type
#endif
int
dl_iterate_phdr(int (*cb)(struct dl_phdr_info *info, size_t size, void
*data),
void *data);
For x86, you can create link.h as well. Or we can guard this define with
MIPS targets.
Why isn't link.h in AOSP Bionic C library?
ARM doesn't use eh_frame, so there is no need to create link.h at the
beginning for the Android project, I guess. For MIPS, we create our own link.h
to work with eh_frame unwinding. Thanks!
[Bug bootstrap/54209] [4.8 Regression] Failed to build gcc for Android/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54209 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2012-08-09 19:08:49 UTC --- (In reply to comment #4) Why isn't link.h in AOSP Bionic C library? ARM doesn't use eh_frame, so there is no need to create link.h at the beginning for the Android project, I guess. For MIPS, we create our own link.h to work with eh_frame unwinding. Thanks! In that case, it should also be added to x86.
[Bug fortran/54208] compilation error for ubound construct in PARAMETER statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54208 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #2 from janus at gcc dot gnu.org 2012-08-09 19:12:44 UTC --- The problem is apparently that, when trying to reduce the constant expression, we only resolve the expression itself (i.e. ubound(arr,1)) but not the array spec of the symbol 'arr'. I find it surprising that this sort of thing has not been reported/fixed before (it may have been reported at least: I have not checked bugzilla for similar PRs). Anyway, the following patchlet gets rid of the error, but may possibly introduce regressions (unchecked): Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c(revision 190186) +++ gcc/fortran/resolve.c(working copy) @@ -5393,6 +5393,8 @@ resolve_variable (gfc_expr *e) gfc_current_ns-parent-parent == sym-ns))) sym-attr.host_assoc = 1; + gfc_resolve_array_spec (sym-as, 0); + resolve_procedure: if (t == SUCCESS resolve_procedure_expression (e) == FAILURE) t = FAILURE;
[Bug target/54212] New: ARM: invalid instruction (vdupeq.32) generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54212 Bug #: 54212 Summary: ARM: invalid instruction (vdupeq.32) generated Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@mansr.com Created attachment 27967 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27967 Test case Compiling the attached file produces the invalid instruction vdupeq.32 (vdup is not conditional). The error occurs only when all of -mcpu=cortex-a9 -mfpu=neon -mfloat-abi=hard -O3 -ffast-math are specified. Targeting other cores or generic armv7-a does not exhibit the problem.
[Bug c++/54213] New: please help to determine wether it is an PostgreSQL error or GCC error (combobox and SQL data sorting)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54213 Bug #: 54213 Summary: please help to determine wether it is an PostgreSQL error or GCC error (combobox and SQL data sorting) Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: lirex.softw...@gmail.com Created attachment 27968 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27968 a c++ source file hello, Windows XP (I guess, that it is an OEM version) Home edition, service pack 3 installed. I use a PostgreSQL database and manipulate data from an GCC c++ application under Windows XP. I use libpq-fe.h library. and I noticed, that if I use an SQL string ... order by... - then it could represent data normally in an combobox element, but if I use a second SQL query to find one field using almost the same query then some ids from 1 and 2 queries are not equal. I found a solution by excluding ... order by But it is not convient to see surnames unsorted... Is it a PostgreSQL error's side or GCC? please help to determine, because I'm not professional on it. My normal compiler options: c++ -ID:\Program Files\PostgreSQL\9.1\include -LD:\Program Files\PostgreSQL\9.1\lib -lpq -o %application_file% %application_file%.cpp -Wl,--subsystem,windows -lgdi32 -lcomctl32 -D_WIN32_IE=0x0300 Compiler options to generate extra debug files: c++ -ID:\Program Files\PostgreSQL\9.1\include -LD:\Program Files\PostgreSQL\9.1\lib -lpq -o %application_file% %application_file%.cpp -Wl,--subsystem,windows -lgdi32 -lcomctl32 -D_WIN32_IE=0x0300 -save-temps Regards, Denis Kolesnik.
[Bug c++/54213] please help to determine whether it is an PostgreSQL error or GCC error (combobox and SQL data sorting)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54213 --- Comment #1 from Denis Kolesnik lirex.software at gmail dot com 2012-08-09 19:56:25 UTC --- Created attachment 27969 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27969 additional files to source asked
[Bug c++/54213] please help to determine whether it is an PostgreSQL error or GCC error (combobox and SQL data sorting)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54213 --- Comment #2 from Denis Kolesnik lirex.software at gmail dot com 2012-08-09 19:57:37 UTC --- Created attachment 27970 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27970 object file
[Bug c++/54213] please help to determine whether it is an PostgreSQL error or GCC error (combobox and SQL data sorting)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54213 --- Comment #3 from Denis Kolesnik lirex.software at gmail dot com 2012-08-09 19:58:55 UTC --- Created attachment 27971 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27971 assembler source file
[Bug c++/54213] please help to determine whether it is an PostgreSQL error or GCC error (combobox and SQL data sorting)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54213 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-08-09 Ever Confirmed|0 |1 Severity|enhancement |minor --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2012-08-09 20:00:56 UTC --- Have you tried to reduce the problem to a simple source file where you only call the PostgreSQL functions? Try that and see what happens. Right now your source is huge and dependent on files most people here don't have access to.
[Bug c++/54213] please help to determine whether it is an PostgreSQL error or GCC error (combobox and SQL data sorting)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54213 Denis Kolesnik lirex.software at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME
[Bug c++/54214] New: (corrected copyright notes in source file)please help to determine whether it is an PostgreSQL error or GCC error (combobox and SQL data sorting)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54214 Bug #: 54214 Summary: (corrected copyright notes in source file)please help to determine whether it is an PostgreSQL error or GCC error (combobox and SQL data sorting) Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: lirex.softw...@gmail.com Created attachment 27972 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27972 a c++ source file hello, I use a PostgreSQL database and manipulate data from an GCC c++ application under Windows XP. I use libpq-fe.h library. and I noticed, that if I use an SQL string ... order by... - then it could represent data normally in an combobox element, but if I use a second SQL query to find one field using almost the same query then some ids from 1 and 2 queries are not equal. I found a solution by excluding ... order by But it is not convient to see surnames unsorted... Is it a PostgreSQL error's side or GCC? please help to determine, because I'm not professional on it. Regards, Denis Kolesnik.
[Bug c++/54214] (corrected copyright notes in source file)please help to determine whether it is an PostgreSQL error or GCC error (combobox and SQL data sorting)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54214 --- Comment #1 from Denis Kolesnik lirex.software at gmail dot com 2012-08-09 20:15:26 UTC --- Created attachment 27973 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27973 additional files to source asked
[Bug c++/54214] (corrected copyright notes in source file)please help to determine whether it is an PostgreSQL error or GCC error (combobox and SQL data sorting)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54214 --- Comment #2 from Denis Kolesnik lirex.software at gmail dot com 2012-08-09 20:18:08 UTC --- Created attachment 27974 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27974 object file
[Bug c++/54214] (corrected copyright notes in source file)please help to determine whether it is an PostgreSQL error or GCC error (combobox and SQL data sorting)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54214 --- Comment #3 from Denis Kolesnik lirex.software at gmail dot com 2012-08-09 20:19:29 UTC --- Created attachment 27975 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27975 assembler source file
[Bug c++/54214] (corrected copyright notes in source file)please help to determine whether it is an PostgreSQL error or a GCC error (combobox and SQL data sorting)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54214 --- Comment #4 from Denis Kolesnik lirex.software at gmail dot com 2012-08-09 20:22:40 UTC --- operation system is Windows XP Home Edition(I guessit is an OEM version) with Service Pack 3 installed.
[Bug c++/54214] (corrected copyright notes in source file)please help to determine whether it is an PostgreSQL error or a GCC error (combobox and SQL data sorting)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54214 --- Comment #5 from Denis Kolesnik lirex.software at gmail dot com 2012-08-09 20:24:54 UTC --- my operation system is Windows XP Home Edition(I guess it is an OEM version) with Service Pack 3 installed.
[Bug middle-end/54211] [4.8 Regression] ICE: verify_gimple failed building freetype with -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54211 William J. Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-08-09 CC||wschmidt at gcc dot gnu.org AssignedTo|unassigned at gcc dot |wschmidt at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #2 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-08-09 20:33:16 UTC --- Confirmed. I'll have a look. For some reason a necessary cast is not being introduced here.
[Bug driver/54210] gcc unable to detect -mprfchw flag in bulldozer machines
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54210 --- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2012-08-09 20:36:47 UTC --- (In reply to comment #1) Is it OK for upstream? Please post the patch to gcc-patches@ mailing list, with correct ChangeLog and testing information.
[Bug middle-end/54211] [4.8 Regression] ICE: verify_gimple failed building freetype with -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54211 --- Comment #3 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-08-09 21:06:22 UTC --- Ah, actually we're generating a POINTER_PLUS_EXPR when a PLUS_EXPR is called for. I see what's going on, shouldn't be hard to fix.
[Bug c++/54214] (corrected copyright notes in source file)please help to determine whether it is an PostgreSQL error or a GCC error (combobox and SQL data sorting)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54214 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-09 21:50:59 UTC --- Why is this marked enhancement ? Is this the same issue as PR 54213 ? If so please close that one. What exactly is your question and why do you think it's anything to do with GCC?
[Bug target/54089] [SH] Refactor shift patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
CC||kkojima at gcc dot gnu.org
--- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org 2012-08-09 21:54:42
UTC ---
I'm currently playing around with the macro SHIFT_COUNT_TRUNCATED (sh.h) and
the target hook TARGET_SHIFT_TRUNCATION_MASK (which is not implemented yet).
Doing the following on rev 190259 (which is actually wrong):
sh.h:
-#define SHIFT_COUNT_TRUNCATED (! TARGET_SH3 ! TARGET_SH2A)
+#define SHIFT_COUNT_TRUNCATED (1)
sh.c:
+/* Implement the TARGET_SHIFT_TRUNCATION_MASK target hook. */
+
+#undef TARGET_SHIFT_TRUNCATION_MASK
+#define TARGET_SHIFT_TRUNCATION_MASK sh_shift_truncation_mask
+
+static unsigned HOST_WIDE_INT
+sh_shift_truncation_mask (enum machine_mode mode)
+{
+ int bitsize = GET_MODE_BIT_SIZE (mode);
+
+ if (TARGET_SHMEDIA)
+return bitsize - 1;
+
+ return MAX (32, bitsize) - 1;
+}
... and looking at some CSiBE size results, I see the a couple of weird cases
similar to what happens to the set_bh_page function in
linux-2.4.23-pre3-testplatform/fs/buffer.c.
Without the changes:
...
.L592:
mov.l .L598,r1 !!
mov r9,r3
mov.l @r1,r2 !! r2 = zone_table[0]
add #124,r2
mov.l @(36,r2),r1
mov.l @(32,r2),r2
add r10,r1
mov.l r9,@(56,r8)
sub r2,r3
mov r3,r2
mov.l .L599,r3
sharr2
sharr2
mul.l r3,r2
mov #12,r3
sts macl,r2
shldr3,r2
add r2,r1
mov.l r1,@(52,r8)
With the changes:
...
.L592:
mov.l @(24,r8),r0 !!
mov r8,r3
mov.l .L598,r1
shlr16 r0!!
shlr8 r0!!
shll2 r0!!
mov.l @(r0,r1),r2 !! r2 = zone_table[page-flags ZONE_SHIFT]
add #124,r2
mov.l @(36,r2),r1
mov.l @(32,r2),r2
add r10,r1
mov.l r8,@(56,r9)
sub r2,r3
mov r3,r2
mov.l .L599,r3
sharr2
sharr2
mul.l r3,r2
mov #12,r3
sts macl,r2
shldr3,r2
add r2,r1
mov.l r1,@(52,r9)
It seems that without the (wrong) patch, the index in the inline function
'page_zone' is reduced from 'page-flags ZONE_SHIFT' to '0', and thus the
resulting code is wrong?!
I've tried to reproduce this in an isolated test case but couldn't get it to do
the same - the generated code seems always correct, with and without the
changes.
I'm confused... Kaz, do you have any idea what could be going on there?
[Bug middle-end/54215] New: [4.8 Regression] 416.gamess in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54215 Bug #: 54215 Summary: [4.8 Regression] 416.gamess in SPEC CPU 2006 failed to build Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x32, revision 190236 gave: gfortran -mx32 -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin aldeci.fppized.o algnci.fppized.o basecp.fppized.o basext.o bashuz.o bashz2.o basn21.fppized.o basn31.o bassto.fppized.o blas.fppized.o ccaux.o ccsdt.fppized.o chgpen.fppized.o cisgrd.fppized.o cosmo.fppized.o cphf.fppized.o cpmchf.o cprohf.fppized.o ddi.fppized.o delocl.fppized.o dft.fppized.o dftaux.fppized.o dftexc.fppized.o dftfun.o dftgrd.fppized.o dftint.fppized.o dgeev.o dmulti.fppized.o drc.fppized.o dummygetenv.fppized.o ecp.fppized.o ecpder.fppized.o ecplib.fppized.o ecppot.o efdrvr.fppized.o efelec.o efgrd2.fppized.o efgrda.fppized.o efgrdb.fppized.o efgrdc.fppized.o efinp.fppized.o efinta.fppized.o efintb.fppized.o efpaul.fppized.o efpcm.fppized.o efpcov.fppized.o eigen.fppized.o eomcc.fppized.o ffield.fppized.o frfmt.fppized.o fsodci.fppized.o gamess.fppized.o globop.fppized.o gradex.fppized.o grd1.fppized.o grd2a.fppized.o grd2b.o grd2c.fppized.o guess.fppized.o gugdga.fppized.o gugdgb.fppized.o gugdm.fppized.o gugdm2.fppized.o gugdrt.fppized.o gugem.fppized.o gugsrt.fppized.o gvb.fppized.o hess.fppized.o hss1a.fppized.o hss1b.fppized.o hss2a.fppized.o hss2b.fppized.o inputa.fppized.o inputb.fppized.o inputc.fppized.o int1.fppized.o int2a.fppized.o int2b.o iolib.fppized.o lagran.fppized.o local.fppized.o loccd.fppized.o locpol.fppized.o mccas.fppized.o mcjac.o mcpinp.fppized.o mcpint.fppized.o mcplib.o mcqdpt.fppized.o mcqdwt.o mcqud.fppized.o mcscf.fppized.o mctwo.fppized.o morokm.fppized.o mp2.fppized.o mp2ddi.fppized.o mp2grd.fppized.o mpcdat.o mpcgrd.fppized.o mpcint.fppized.o mpcmol.fppized.o mpcmsc.fppized.o mthlib.fppized.o nameio.fppized.o nmr.fppized.o olix.o ordint.fppized.o ormas1.fppized.o parley.fppized.o pcm.fppized.o pcmcav.o pcmcv2.fppized.o pcmder.fppized.o pcmdis.fppized.o pcmief.fppized.o pcmpol.fppized.o pcmvch.fppized.o prpel.fppized.o prplib.fppized.o prppop.fppized.o qeigen.fppized.o qfmm.fppized.o qmfm.fppized.o qmmm.fppized.o qrel.fppized.o raman.fppized.o rhfuhf.fppized.o rxncrd.fppized.o ryspol.o scflib.fppized.o scfmi.fppized.o scrf.fppized.o sobrt.fppized.o soffac.fppized.o solib.fppized.o sozeff.fppized.o statpt.fppized.o surf.fppized.o symorb.fppized.o symslc.fppized.o tdhf.fppized.o trans.fppized.o trfdm2.fppized.o trnstn.fppized.o trudge.fppized.o umpddi.fppized.o unport.fppized.o vibanl.fppized.o vscf.fppized.o zheev.fppized.o zmatrx.fppized.o -lm-o gamess In file included from :65:0: qfmm.fppized.f: In function 'sp2p': qfmm.fppized.f:3040:0: error: type mismatch in pointer plus expression SUBROUTINE SP2P(IYZTBL,F,G,CLM,FLM,ZLL ^ unsigned int unsigned int sizetype D.37741_1456 = D.37738_1521 + slsr.4164_1172; qfmm.fppized.f:3040:0: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[4]: *** [/tmp/ccdYEqh9.ltrans8.ltrans.o] Error 1 lto-wrapper: make returned 2 exit status /usr/local/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status specmake[3]: *** [gamess] Error 1
[Bug middle-end/54215] [4.8 Regression] 416.gamess in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54215 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Depends on||54211 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-08-09 22:21:36 UTC --- I bet the problem here is the same problem as PR 54211.
[Bug target/39423] [4.6/4.7/4.8 Regression] [SH] performance regression: lost mov @(disp,Rn)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39423 --- Comment #25 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-08-09 22:44:41 UTC --- (In reply to comment #24) I'm not sure whether this should be back ported to 4.6.x or 4.7.x or not. Kaz, what do you think? Looks a bit intrusive for the stable branches.
[Bug target/54089] [SH] Refactor shift patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org 2012-08-09 23:17:54
UTC ---
OK, I checking out the preprocessed file reveals the following relevant pieces:
typedef struct page {
struct list_head list;
struct address_space *mapping;
unsigned long index;
struct page *next_hash;
atomic_t count;
unsigned long flags;//
struct list_head lru;
struct page **pprev_hash;
struct buffer_head * buffers;
} mem_map_t;
static inline zone_t *page_zone(struct page *page)
{
return zone_table[page-flags (64 - 8)]; // = page-flags 56
}
Depending on whether SHIFT_COUNT_TRUNCATED evals to 1 or 0, the function above
returns either zone_table[0] (dyn shifts) or zone_table[page-flags 24] (no
dyn shifts). Both should be OK to do, since that's undefined behavior.
In this case maybe fixing SHIFT_COUNT_TRUNCATED to '0' would be better, since
that would produce faster undefined behavior code ;)
[Bug c++/54180] a bug using strcat function - it depends on variable declare order, but it should not.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54180 Denis Kolesnik lirex.software at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #5 from Denis Kolesnik lirex.software at gmail dot com 2012-08-09 23:19:16 UTC --- The syntax of the programming language C++ includes the syntax of the programming language C and also it should handle such common functions as strcat. So if I define variables in a such way: CHAR SQL1[150], SQL2[150], SQL_date_payment[10], SQL_date_begin[10], SQL_date_end[10], SQL_result[100]; instead of: CHAR SQL_date_payment[10],SQL_date_begin[10], SQL_date_end[10], SQL1[150], SQL2[150], SQL_result[100]; (where variables for dates which I form using strcpy and strcat functions stay after SQL1) it should work without problems, because of programming language syntax which is a standart. But it works so, that SQL1 partially overwrites value of SQL_date_begin and values are not such as expected. I never heard, that the C language is outdated. The C++ is just another standart which includes the syntax of C. So I consider it is as an GCC error which should be fixed, also because all standart libraries come along with GCC.
[Bug c++/54180] a bug using strcat function - it depends on variable declare order, but it should not.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54180 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org 2012-08-09 23:22:22 UTC --- The order of the variables is not the issue. The issue is you are writing past the array bounds of the variables which is undefined.
[Bug target/54089] [SH] Refactor shift patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org 2012-08-09 23:27:55 UTC --- Author: olegendo Date: Thu Aug 9 23:27:51 2012 New Revision: 190273 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190273 Log: PR target/54089 * config/sh/sh-protos (shift_insns_rtx): Delete. (sh_ashlsi_clobbers_t_reg_p): Add. * config/sh/sh.c (shift_insns, shift_amounts, ext_shift_insns, ext_shift_amounts): Merge arrays of ints to array of structs. Adapt usage of arrays throughout the file. (shift_insns_rtx): Delete unused function. (sh_ashlsi_clobbers_t_reg_p): New function. * config/sh/sh.md (ashlsi3): Emit ashlsi3_n_clobbers_t insn if the final shift sequence will clobber T_REG. (ashlsi3_n): Split only if the final shift sequence will not clobber T_REG. (ashlsi3_n_clobbers_t): New insn_and_split. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh-protos.h trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.md
[Bug c++/54180] a bug using strcat function - it depends on variable declare order, but it should not.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54180 Denis Kolesnik lirex.software at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #7 from Denis Kolesnik lirex.software at gmail dot com 2012-08-09 23:33:15 UTC --- all those variables are defined, otherwise it would not compile. The main is, that it is normal(both cases) for the C language syntax and both declaration orders should work. That is why it is a bug.
[Bug c++/54180] a bug using strcat function - it depends on variable declare order, but it should not.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54180 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org 2012-08-09 23:35:06 UTC --- (In reply to comment #7) all those variables are defined, otherwise it would not compile. The main is, that it is normal(both cases) for the C language syntax and both declaration orders should work. With the correct lengths? Writing past the array bounds in both C and C++ is not required a diagnostic, it just invokes undefined behavior.
[Bug target/54089] [SH] Refactor shift patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #7 from Oleg Endo olegendo at gcc dot gnu.org 2012-08-09 23:36:10 UTC --- Kaz, another thing I'm a bit unsure about ... #define SH_DYNAMIC_SHIFT_COST \ (TARGET_HARD_SH4 ? 1 : TARGET_DYNSHIFT ? (optimize_size ? 1 : 2) : 20) Do you have any idea, why this is not simply #define SH_DYNAMIC_SHIFT_COST (TARGET_DYNSHIFT) ? I've checked the HW manuals for SH2A, SH3 and SH4 and all state that dynamic shifts take one cycle, i.e. are as fast/slow as the other constant shift insns...
[Bug c++/54213] please help to determine whether it is an PostgreSQL error or GCC error (combobox and SQL data sorting)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54213 --- Comment #5 from Denis Kolesnik lirex.software at gmail dot com 2012-08-09 23:37:18 UTC --- please see comments for the bug 54214, because it is the same, but with corrected copyright notes.
[Bug target/54089] [SH] Refactor shift patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #8 from Oleg Endo olegendo at gcc dot gnu.org 2012-08-09 23:42:57 UTC --- (In reply to comment #7) Kaz, another thing I'm a bit unsure about ... #define SH_DYNAMIC_SHIFT_COST \ (TARGET_HARD_SH4 ? 1 : TARGET_DYNSHIFT ? (optimize_size ? 1 : 2) : 20) Do you have any idea, why this is not simply #define SH_DYNAMIC_SHIFT_COST (TARGET_DYNSHIFT) ? Sorry, I meant: #define SH_DYNAMIC_SHIFT_COST (TARGET_DYNSHIFT ? 1 : 20)
[Bug bootstrap/54128] GCC does not bootstrap on little endian mips due to mis-compare on tree-data-ref.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54128 --- Comment #5 from Steve Ellcey sje at gcc dot gnu.org 2012-08-09 23:46:52 UTC --- Created attachment 27976 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27976 Cutdown test case I have attached a new test case, cut down from the original. I have duplicated the bug using a x86 to mips cross compiler and the mips-unknown-linux-gnu target so it doesn't look specific to little-endian. I get the difference in instruction scheduling with -mips1 or -mips32r2 and with no options other then -O2 so it doesn't seem specific to a particular mips architecture either. The difference with and without -g is in the instruction scheduling and sometimes with the register selection.
[Bug c++/54216] New: Missing diagnostic for ill-formed anonymous enum declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54216
Bug #: 54216
Summary: Missing diagnostic for ill-formed anonymous enum
declarations
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: frankhb1...@gmail.com
G++(-pedantic-errors) wrongly accepts following non-conforming enumeration
declarations(in namespace scope or block scope) and no diagnostic output at
all:
enum {}; //-std=c++98 or -std=c++11
enum class {}; //-std=c++11
enum class { x }; //-std=c++11
According the standard, all of them are ill-formed:
(for the first declaration)
ISO C++98/03/11
7/3 ...
[Example:
enum { }; // ill-formed
typedef class { }; // ill-formed
—end example]
(for others)
ISO C++11
7.2/2 ... The optional identifier shall not be omitted in the declaration of a
scoped enumeration. ...
While clang++(trunk, also using -pedantic-errors) rejects them correctly:
(for the first declaration, -std=c++98 or -std=c++11)
error: declaration does not declare anything
[-Werror,-Wmissing-declarations]
enum {};
^~~~
(for others, -std=c++11)
error: scoped enumeration requires a name
enum class { };
^
error: declaration does not declare anything
[-Werror,-Wmissing-declarations]
enum class { };
^~~~
error: scoped enumeration requires a name
enum class { x };
^
[Bug c++/54216] Missing diagnostic for ill-formed anonymous enum declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54216 frankhb1989 at gmail dot com changed: What|Removed |Added Severity|normal |minor
[Bug middle-end/54217] New: setup_save_areas() duplicates hard reg uses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54217 Bug #: 54217 Summary: setup_save_areas() duplicates hard reg uses Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@redhat.com Created attachment 27977 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27977 patch to check for duplicate hard reg uses setup_save_areas() in caller-save.c sometimes (with -fira-share-save-slots) maps one hard reg to two different saved regs. Since the save arrays are sized to [FIRST_PSEUDO_REGISTER] this means the arrays may overflow. The attached test case demonstrates the error, the attached patch checks for the error and forces an abort when it's detected. Note: at the time I discovered this, newlib (from whence the test case came) would show this error somewhere for these *-elf targets: bfin cris m32c rl78 rx sh sh64 v850
[Bug middle-end/54217] setup_save_areas() duplicates hard reg uses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54217 --- Comment #1 from DJ Delorie dj at redhat dot com 2012-08-10 00:22:22 UTC --- Created attachment 27978 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27978 test case for rl78-elf, from newlib
[Bug target/54089] [SH] Refactor shift patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #9 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-08-10 00:39:50 UTC --- (In reply to comment #8) #define SH_DYNAMIC_SHIFT_COST (TARGET_DYNSHIFT ? 1 : 20) Sounds reasonable. Perhaps some historical reason for the original one, though I don't know why. Could you run SCiBE tests with it?
[Bug middle-end/54211] [4.8 Regression] ICE: verify_gimple failed building freetype with -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54211 --- Comment #4 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-08-10 01:14:41 UTC --- The following patch is tested and awaiting approval: Index: gcc/gimple-ssa-strength-reduction.c === --- gcc/gimple-ssa-strength-reduction.c(revision 190260) +++ gcc/gimple-ssa-strength-reduction.c(working copy) @@ -2534,7 +2534,7 @@ analyze_candidates_and_replace (void) /* Determine whether we'll be generating pointer arithmetic when replacing candidates. */ address_arithmetic_p = (c-kind == CAND_ADD - POINTER_TYPE_P (TREE_TYPE (c-base_expr))); + POINTER_TYPE_P (c-cand_type)); /* If all candidates have already been replaced under other interpretations, nothing remains to be done. */
[Bug middle-end/54215] [4.8 Regression] 416.gamess in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54215 William J. Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||wschmidt at gcc dot gnu.org Resolution||DUPLICATE --- Comment #2 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-08-10 01:16:07 UTC --- Correct, this is a dup. Thanks, Andrew. *** This bug has been marked as a duplicate of bug 54211 ***
[Bug middle-end/54211] [4.8 Regression] ICE: verify_gimple failed building freetype with -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54211 William J. Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #5 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-08-10 01:16:07 UTC --- *** Bug 54215 has been marked as a duplicate of this bug. ***
[Bug middle-end/54146] Very slow compile with attribute((flatten))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 --- Comment #37 from Jan Hubicka hubicka at ucw dot cz 2012-08-10 03:45:31 UTC --- I suppose it's the old issue that we update fibheap keys along each inlining decision - and with flatten there are just very many ... Honza? Well, I killed most of updating for mainline and at flattening time the keys are not even computed. So it is probably some other bookeping. I will profile it. It also seems we flatten depth-first (thus inline leafs) instead of the other way around: orig_callee = callee; inline_call (e, true, NULL, NULL); if (e-callee != orig_callee) orig_callee-symbol.aux = (void *) node; flatten_function (e-callee, early); if (e-callee != orig_callee) orig_callee-symbol.aux = NULL; This means we will materialize all intermediate flattenings in functions that will not be reclaimed, right? flattening foo should inline everything into foo, but not affect remaining callee bodies. I do not follow here. Callee is already the inline clone, so we will not affect other copies of foo... Honza Richard. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug middle-end/54146] Very slow compile with attribute((flatten))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 --- Comment #38 from Jan Hubicka hubicka at ucw dot cz 2012-08-10 03:50:26 UTC --- I don't understand how inline_merge_summary is supposed to work, so I'm going to leave that one for Richi and Honza. Well, it produces inline summary for function that is result of inlininig based on summaries of the former functions. You can't just bypass it for flattening or the summary of the function after flatting will be off. Obviously the function does fair amount of propagation. I will try to speed it up or limit the bounds. Since the summaries are of constant size, we should not explode here. Honza
[Bug middle-end/54146] Very slow compile with attribute((flatten))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 --- Comment #39 from Jan Hubicka hubicka at ucw dot cz 2012-08-10 03:53:46 UTC --- Martin, can you look at comment #14 and the patch? I think what we want to do in flatten_function is before inline_call (e, true, NULL, NULL); reset the edge predicates so that inline_merge_summary becomes very cheap. Well, this will still result in (conservatively) wrong inline summary for flattened function. I am not sure if flatten attribute should laso mean do not care about inlining of the flattened function much. I think we want to handle this generically even if it is harder for small function inliner to explode here because it does a lot less cascaded inlining. Unfortunately that beast seems to have no early out (but instead uses true_predicate () ...). Can we speed it up for the case where we just want fast operation rather than precise accounting of sizes/time in the inlined-to caller? I will look. Honza
[Bug middle-end/54146] Very slow compile with attribute((flatten))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 --- Comment #40 from Jan Hubicka hubicka at gcc dot gnu.org 2012-08-10 04:34:54 UTC --- OK, my simple ^C profiling shows: #14 0x0091f17f in estimate_edge_size_and_time (e=0x7fffb7192d68, size=optimized out, time=0x7fffc04110b0, prob=1) at ../../gcc/ipa-inline-analysis.c:2183 #15 0x0091f23a in estimate_calls_size_and_time (node=0x7fffb7193af8, size=0x7fffc04110b4, time=0x7fffc04110b0, possible_truths=4294967294, known_vals=0x0, known_binfos=0x0) at ../../gcc/ipa-inline-analysis.c:2274 #16 0x0091f2d1 in estimate_calls_size_and_time (node=0x7fffb71939c0, size=0x7fffc04110b4, time=0x7fffc04110b0, possible_truths=4294967294, known_vals=0x0, known_binfos=0x0) at ../../gcc/ipa-inline-analysis.c:2277 #17 0x0091f2d1 in estimate_calls_size_and_time (node=0x7fffb7193888, size=0x7fffc04110b4, time=0x7fffc04110b0, possible_truths=4294967294, known_vals=0x0, known_binfos=0x0) at ../../gcc/ipa-inline-analysis.c:2277 #18 0x0091f2d1 in estimate_calls_size_and_time (node=0x7fffb7191c30, size=0x7fffc04110b4, time=0x7fffc04110b0, possible_truths=4294967294, known_vals=0x0, known_binfos=0x0) at ../../gcc/ipa-inline-analysis.c:2277 #19 0x0091f2d1 in estimate_calls_size_and_time (node=0x7fffb7180c30, size=0x7fffc04110b4, time=0x7fffc04110b0, possible_truths=4294967294, known_vals=0x0, known_binfos=0x0) at ../../gcc/ipa-inline-analysis.c:2277 #20 0x0091f2d1 in estimate_calls_size_and_time (node=0x7fffb7147d68, size=0x7fffc04110b4, time=0x7fffc04110b0, possible_truths=4294967294, known_vals=0x0, known_binfos=0x0) at ../../gcc/ipa-inline-analysis.c:2277 #21 0x0091f2d1 in estimate_calls_size_and_time (node=0x7fffcbb039c0, size=0x7fffc04110b4, time=0x7fffc04110b0, possible_truths=4294967294, known_vals=0x0, known_binfos=0x0) at ../../gcc/ipa-inline-analysis.c:2277 #22 0x009232a1 in inline_merge_summary (edge=0x7fffb6fba068) at ../../gcc/ipa-inline-analysis.c:2687 #23 0x00ed0cdf in inline_call (e=0x7fffb6fba068, update_original=optimized out, new_edges=0x0, overall_size=0x0) at ../../gcc/ipa-inline-transform.c:246 #24 0x00ece3a9 in flatten_function (node=0x7fffb6fb9ea0, early=1 '\001') at ../../gcc/ipa-inline.c:1605 #25 0x00ece3bf in flatten_function (node=0x7fffb6fb4c30, early=1 '\001') at ../../gcc/ipa-inline.c:1608 #26 0x00ece3bf in flatten_function (node=0x7fffb6f87270, early=1 '\001') at ../../gcc/ipa-inline.c:1608 #27 0x00ece3bf in flatten_function (node=0x7fffcbb039c0, early=1 '\001') at ../../gcc/ipa-inline.c:1608 #28 0x00ece616 in early_inliner () at ../../gcc/ipa-inline.c:1881 so the time is actually not spent in the predicate merging logic, but in computing overall size/time of the function after inline operation is performed. This is because of following call in inline_merge_summary: estimate_calls_size_and_time (to, info-size, info-time, ~(clause_t)(1 predicate_false_condition), NULL, NULL); Here we simply recompute the size/time by walking all callees of the function and since this involve recursive walk of the inlined callees that are many we hit quadratic time complexity. Ugly. One (particularly ugly) workaround would be to make inline_merge_summary to skip updating after each step of flattening because flattening do not care, but that is quite a kludge (similar to Steven's patch but with one extra update on the very end). Other solution is to work hard enough to update everything incrementally, but it is not 100% trivial (that is why I simply recompute). I actually tought of this case and concluded that if we do so deep inline trees we will blow up somewhere else. Quite an achivement that Steven managed to chase out all the other cases. Honza
[Bug middle-end/54146] Very slow compile with attribute((flatten))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 --- Comment #41 from Jan Hubicka hubicka at gcc dot gnu.org 2012-08-10 05:18:52 UTC --- Created attachment 27979 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27979 Path for inliner slowness Hi, this is patch I am testing. After some consideration I do not like the incremental update idea much. It asks for bookkeeping issues and has roundoff problems so unless it is really necessary I will try to stick with the recomputation scheme. This is more careful variant of Steven's patch. We skip the recomputation after each incremental inline and update the info once we are done with the flattening. Honza
[Bug rtl-optimization/48133] [4.6/4.7/4.8 Regression] ICE: in get_loop_body, at cfgloop.c:831 with -O -funroll-loops -fthread-jumps -fno-tree-ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48133 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #13 from Jan Hubicka hubicka at gcc dot gnu.org 2012-08-10 05:38:10 UTC --- This seems to work for me now jh@gcc10:~/trunk/build/gcc$ ./gfortran -O2 -c t.f90 -B ./ jh@gcc10:~/trunk/build/gcc$ cat t.f90 SUBROUTINE goo() IMPLICIT NONE CHARACTER(len=9),SAVE :: s INTEGER,SAVE :: i,j,k i=0 j=0 DO WHILE (i==0) CALL goo1(s) IF (INDEX(s,'$')/=1 .AND. INDEX(s,'!')/=1) THEN CALL goo2(k) IF (k0) THEN i=1 END IF END IF END DO END SUBROUTINE ! gfortran -O2 -c goo.f90 (similarly with the C testcase). It would be nice to know what fixed it. H.J, do you think you can track it?
