[Bug c++/37552] New: [4.4 regression] ICE with invalid array access
The following invalid code snippet triggers an ICE on mainline:
extern struct A a[1];
void foo()
{
a[0];
}
bug.cc: In function 'void foo()':
bug.cc:5: error: invalid use of incomplete type 'struct A'
bug.cc:1: error: forward declaration of 'struct A'
bug.cc:5: internal compiler error: tree check: expected class 'expression',
have 'exceptional' (error_mark) in build_array_ref, at cp/typeck.c:2626
Please submit a full bug report, [etc.]
The regression appeared between 2008-08-29 and 2008-09-06.
--
Summary: [4.4 regression] ICE with invalid array access
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37552
[Bug c++/37552] [4.4 regression] ICE with invalid array access
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37552
[Bug c++/37553] New: ICE in build_c_cast
This code triggers an ICE in gcc-4.3.1 on i686 when compiled with g++:
typedef unsigned int ui32;
__extension__ typedef unsigned long long int ui64;
typedef ui32 __attribute__ ((__may_alias__)) ui32a;
typedef ui64 __attribute__ ((__may_alias__)) ui64a;
union u_u32
{
ui32a v;
} __attribute__ ((__may_alias__));
union u_u64
{
ui64a v;
struct
{
union u_u32 lo32, hi32;
} u;
} __attribute__ ((__may_alias__));
void
out_long (ui64 longVal)
{
if ((*(union u_u64 *) longVal).u.lo32.v 0x1000ul)
{
if ((ui32) ((*(union u_u64 *) longVal).u.lo32.v) 0x4000u)
{
/* do something useful */
}
}
}
longs3.c: In function 'void out_long(ui64)':
longs3.c:24: internal compiler error: in build_c_cast, at cp/typeck.c:5631
--
Summary: ICE in build_c_cast
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: patrakov at gmail dot com
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=37553
[Bug c++/37554] New: [4.3/4.4 regression] ICE with invalid cast
The following invalid code snippet triggers an ICE since GCC 4.3.0:
struct A {};
class B : A {};
void foo(B b)
{
(A)b;
}
bug.cc: In function 'void foo(B)':
bug.cc:6: error: 'A' is an inaccessible base of 'B'
bug.cc:6: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in useless_type_conversion_p_1, at tree-ssa.c:1075
Please submit a full bug report, [etc.]
--
Summary: [4.3/4.4 regression] ICE with invalid cast
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37554
[Bug c++/37554] [4.3/4.4 regression] ICE with invalid cast
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37554
[Bug c++/37555] New: [4.1/4.2/4.3/4.4 regression] ICE with invalid typedef
The following invalid code snippet triggers an ICE since GCC 3.4.0:
struct A {};
typedef void (A::T)();
void foo()
{
T t;
t;
}
bug.cc:3: error: typedef name may not be a nested-name-specifier
bug.cc: In function 'void foo()':
bug.cc:8: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
--
Summary: [4.1/4.2/4.3/4.4 regression] ICE with invalid typedef
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37555
[Bug c++/37555] [4.1/4.2/4.3/4.4 regression] ICE with invalid typedef
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37555
[Bug c++/37556] New: [4.4 regression] ICE with invalid typedef
The following invalid code snippet triggers an ICE on mainline:
struct A
{
void foo();
};
typedef void (A::T)();
void bar(T);
void baz()
{
bar(A::foo);
}
bug.cc:6: error: typedef name may not be a nested-name-specifier
bug.cc:8: error: parameter 'anonymous' invalidly declared method type
bug.cc: In function 'void baz()':
bug.cc:12: internal compiler error: canonical types differ for identical types
void (A::*)() and void (A::*)()
Please submit a full bug report, [etc.]
The regression appeared between 2008-07-29 and 2008-08-23.
The bug is related to PR37555, but a more recent regression.
--
Summary: [4.4 regression] ICE with invalid typedef
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37556
[Bug c++/37556] [4.4 regression] ICE with invalid typedef
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37556
[Bug c++/37557] New: mixing wide and plain streams causes stream-errors (g++ 4.2.3 also affected)
hi, recetly i found out something that is possible/probably bug in g++. so far i have tested on 4.1.0 and 4.2.3. on previous versions there were no such error (tried with 3.3.5). here is brief description: i use string and wstring (and appropriate cin/cout and wcin/wcout) in same console app that simulates user login (for both ascii and wide). i display 'menu' for user to 'choose' will it try to 'login' with wide or ascii strings. if i uses ascii 'menu', then ascii 'login' works, but wide not. on the other hand, if i use wide strings for 'menu', ascii 'login' does not work, but wide do work. it seems that g++ can not use (or better say, do not use properly) stream of type other than initial stream type here are g++ versions that fails: --- 4.1.0 (not working) --- [EMAIL PROTECTED]:~/tmp g++ -v -save-temps test.cpp Using built-in specs. Target: x86_64-suse-linux Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.0 --enable-ssp --disable-libssp --enable-java-awt=gtk --enable-gtk-cairo --disable-libjava-multilib --with-slibdir=/lib64 --with-system-zlib --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --without-system-libunwind --with-cpu=generic --host=x86_64-suse-linux Thread model: posix gcc version 4.1.0 (SUSE Linux) /usr/lib64/gcc/x86_64-suse-linux/4.1.0/cc1plus -E -quiet -v -D_GNU_SOURCE test.cpp -mtune=generic -fpch-preprocess -o test.ii #include ... search starts here: #include ... search starts here: /usr/include/c++/4.1.0 /usr/include/c++/4.1.0/x86_64-suse-linux /usr/include/c++/4.1.0/backward /usr/local/include /usr/lib64/gcc/x86_64-suse-linux/4.1.0/include /usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../../../x86_64-suse-linux/include /usr/include End of search list. /usr/lib64/gcc/x86_64-suse-linux/4.1.0/cc1plus -fpreprocessed test.ii -quiet -dumpbase test.cpp -mtune=generic -auxbase test -version -o test.s GNU C++ version 4.1.0 (SUSE Linux) (x86_64-suse-linux) compiled by GNU C version 4.1.0 (SUSE Linux). GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64086 Compiler executable checksum: 9b76824cc9116a4f771ea2bae2ced729 /usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../../../x86_64-suse-linux/bin/as -V -Qy -o test.o test.s GNU assembler version 2.16.91.0.5 (x86_64-suse-linux) using BFD version 2.16.91.0.5 20051219 (SUSE Linux) /usr/lib64/gcc/x86_64-suse-linux/4.1.0/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../../../lib64/crt1.o /usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../../../lib64/crti.o /usr/lib64/gcc/x86_64-suse-linux/4.1.0/crtbegin.o -L/usr/lib64/gcc/x86_64-suse-linux/4.1.0 -L/usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../../../x86_64-suse-linux/lib -L/usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../.. test.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib64/gcc/x86_64-suse-linux/4.1.0/crtend.o /usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../../../lib64/crtn.o --- 4.2.3 (not working) --- [EMAIL PROTECTED]:~/tmp$ g++ -v -save-temps test.cpp Reading specs from /usr/lib/gcc/i486-slackware-linux/4.2.3/specs Target: i486-slackware-linux Configured with: ../gcc-4.2.3/configure --prefix=/usr --enable-shared --enable-languages=ada,c,c++,fortran,java,objc --enable-threads=posix --enable-__cxa_atexit --disable-checking --with-gnu-ld --verbose --with-arch=i486 --target=i486-slackware-linux --host=i486-slackware-linux Thread model: posix gcc version 4.2.3 /usr/libexec/gcc/i486-slackware-linux/4.2.3/cc1plus -E -quiet -v -D_GNU_SOURCE test.cpp -mtune=i486 -march=i486 -fpch-preprocess -o test.ii ignoring duplicate directory /usr/lib/qt/include ignoring nonexistent directory /usr/lib/gcc/i486-slackware-linux/4.2.3/../../../../i486-slackware-linux/include #include ... search starts here: #include ... search starts here: /usr/lib/qt/include /usr/lib/gcc/i486-slackware-linux/4.2.3/../../../../include/c++/4.2.3 /usr/lib/gcc/i486-slackware-linux/4.2.3/../../../../include/c++/4.2.3/i486-slackware-linux /usr/lib/gcc/i486-slackware-linux/4.2.3/../../../../include/c++/4.2.3/backward /usr/local/include /usr/lib/gcc/i486-slackware-linux/4.2.3/include /usr/include End of search list. /usr/libexec/gcc/i486-slackware-linux/4.2.3/cc1plus -fpreprocessed test.ii -quiet -dumpbase test.cpp -mtune=i486 -march=i486 -auxbase test -version -o test.s GNU C++ version 4.2.3 (i486-slackware-linux)
[Bug fortran/37545] impossible to link with -fopenmp
--- Comment #4 from francois dot jacq at irsn dot fr 2008-09-17 07:18 --- Subject: Re: impossible to link with -fopenmp Le mardi 16 septembre 2008 20:26, pinskia at gcc dot gnu dot org a écrit : --- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-16 18:26 --- Did you compile gfortran yourself or are you using a prebuilt package? I just downloaded the prebuilt package proposed by GfortranWiki -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37545
[Bug fortran/37274] [Regression 4.4 (and 4.3?)] error: type name is ambiguous.
--- Comment #17 from pault at gcc dot gnu dot org 2008-09-17 07:31 --- (In reply to comment #16) Lest anybody is worrying about the patch that I posted, I cannot commit until tonight or tomorrow morning. Since my laptop was stolen, I have no means to update my tree nor commit anything when I am on the road - my work laptop does not give me administrator rights:-( Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37274
[Bug fortran/37545] impossible to link with -fopenmp
--- Comment #5 from francois dot jacq at irsn dot fr 2008-09-17 07:34 --- Subject: Re: impossible to link with -fopenmp Le mardi 16 septembre 2008 20:50, dfranke at gcc dot gnu dot org a écrit : --- Comment #2 from dfranke at gcc dot gnu dot org 2008-09-16 18:50 --- Mandriva 2007.1 What's the version of your glibc? If less than 2.6, try upgrading. I guess this is a downloaded package that meets an (somewhat) outdated system ... Yes you are right but if I can upgrade my system at Home (Mandriva 2007.1), I cannot do the same at office (Debian etch for everybody and for several years). I previously used Gfortran-4.3.0 prebuilt package, also implementing OpenMP, and this one did not have this trouble (but had few others). Unfortunately, this package has disappeared from GfortranWiki. I would like to underline that the proposed package is assumed to be complete and not to interact with any other previous installed version (this is written in GfortranWiki). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37545
[Bug ada/21327] gnat_ugn.texi invalid @direntry
--- Comment #5 from sam at gcc dot gnu dot org 2008-09-17 07:59 --- Subject: Bug 21327 Author: sam Date: Wed Sep 17 07:58:12 2008 New Revision: 140411 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140411 Log: 2008-09-17 Pascal Rigaux [EMAIL PROTECTED] gcc/ada/ PR ada/21327 * gnat_ugn.texi: Use proper format in direntry. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gnat_ugn.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21327
[Bug ada/21327] gnat_ugn.texi invalid @direntry
--- Comment #6 from sam at gcc dot gnu dot org 2008-09-17 08:00 --- Pascal's fix committed as trivial documentation fix in SVN trunk. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21327
[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5
--- Comment #34 from jorn dot amundsen at ntnu dot no 2008-09-17 08:02 --- (In reply to comment #33) Thank you for the tip on libtool libpath. Looking into it with dump -H, I did not know it was that ugly. Indeed, this should be cleaned up if when building and installing software. In order to reproduce your successful compilation, I did 0. shared mpfr 2.3.1, shared gmp 4.2.3, shared gettext 0.10.40 1. untar 4.3.2 gcc-core and gcc-g++ 2. apply pt.c patch 3. environ settings: export CONFIG_SHELL=/opt/freeware/bin/bash export CONFIGURE_ENV_ARGS=/opt/freeware/bin/bash export OBJECT_MODE=32 4. mkdir objdir 5. cd objdir 6. ../configure --enable-languages=c,c++ 7. gmake bootstrap 8. objdir/gcc/g++ -Bobjdir/gcc -c icefiles.ii This works! I am able to reproduce your successful compilation of every .ii file attached to this bug. The reason for the remaining failures is any of - a bug in any of the IBM GCC 4.2 RPM patches - one or more of the 4.2 hunks are not applicable with 4.3 - I made an error in porting any of the 4.2 hunks to 4.3 Having a build tree which breaks and another with works I am now able to limit and eventually find the root cause of this problem. Hence this issue is resolved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37057
[Bug rtl-optimization/37544] [4.2/4.3/4.4 Regression] Conversion double - unsigned long long - unsigned - double gives wrong results
--- Comment #6 from ubizjak at gmail dot com 2008-09-17 08:14 ---
cprop_hardreg pass is propagating DImode ax register, wrongly bypassing DI-SI
conversion.
Before cprop_hardreg, we have:
(call_insn/u:HI 27 88 28 4 pr37544.c:9 (set (reg:DI 0 ax)
(call (mem:QI (symbol_ref:SI (__fixunsdfdi) [flags 0x41]) [0 S1 A8])
(const_int 16 [0x10]))) 687 {*call_value_0} (expr_list:REG_UNUSED
(reg:SI 1 dx)
(expr_list:REG_EH_REGION (const_int -1 [0x])
(nil)))
(expr_list:REG_DEP_TRUE (use (mem:DF (plus:SI (reg/f:SI 7 sp)
(scratch:SI)) [0 S8 A8]))
(nil)))
(insn 95 28 104 4 pr37544.c:9 (set (reg:SI 21 xmm0)
(reg:SI 0 ax [78])) 41 {*movsi_1} (expr_list:REG_DEAD (reg:SI 0 ax
[78])
(nil)))
(insn 104 95 105 4 pr37544.c:9 (set (mem/c:DI (plus:SI (reg/f:SI 6 bp)
(const_int -8032 [0xe0a0])) [0 S8 A64])
(reg:DI 21 xmm0)) 63 {*movdi_2} (expr_list:REG_DEAD (reg:DI 21 xmm0)
(nil)))
(insn 105 104 89 4 pr37544.c:9 (set (reg/v:DF 8 st [orig:65 b ] [65])
(float:DF (mem/c:DI (plus:SI (reg/f:SI 6 bp)
(const_int -8032 [0xe0a0])) [0 S8 A64]))) 179
{*floatdidf2_i387} (nil))
and after cprop_hardreg:
(call_insn/u:HI 27 88 28 4 pr37544.c:9 (set (reg:DI 0 ax)
(call (mem:QI (symbol_ref:SI (__fixunsdfdi) [flags 0x41]) [0 S1 A8])
(const_int 16 [0x10]))) 687 {*call_value_0} (expr_list:REG_UNUSED
(reg:SI 1 dx)
(expr_list:REG_EH_REGION (const_int -1 [0x])
(nil)))
(expr_list:REG_DEP_TRUE (use (mem:DF (plus:SI (reg/f:SI 7 sp)
(scratch:SI)) [0 S8 A8]))
(nil)))
(insn 95 28 104 4 pr37544.c:9 (set (reg:SI 21 xmm0)
(reg:SI 0 ax [78])) 41 {*movsi_1} (expr_list:REG_DEAD (reg:SI 0 ax
[78])
(nil)))
(insn 104 95 105 4 pr37544.c:9 (set (mem/c:DI (plus:SI (reg/f:SI 6 bp)
(const_int -8032 [0xe0a0])) [0 S8 A64])
(reg:DI 0 ax [21])) 63 {*movdi_2} (expr_list:REG_DEAD (reg:DI 21 xmm0)
(nil)))
(insn 105 104 89 4 pr37544.c:9 (set (reg/v:DF 8 st [orig:65 b ] [65])
(float:DF (mem/c:DI (plus:SI (reg/f:SI 6 bp)
(const_int -8032 [0xe0a0])) [0 S8 A64]))) 179
{*floatdidf2_i387} (nil))
Please note, how DImode ax reg propagates into (insn 104), bypassing SImode
conversion in (insn 95).
--
ubizjak at gmail dot com changed:
What|Removed |Added
Component|target |rtl-optimization
Priority|P3 |P1
Summary|Conversion double -|[4.2/4.3/4.4 Regression]
|unsigned long long - |Conversion double -
|unsigned - double gives|unsigned long long -
|wrong results |unsigned - double gives
||wrong results
Target Milestone|--- |4.2.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37544
[Bug rtl-optimization/37544] [4.2/4.3/4.4 Regression] Conversion double - unsigned long long - unsigned - double gives wrong results
--- Comment #7 from ubizjak at gmail dot com 2008-09-17 08:35 --- (In reply to comment #5) Confirmed on i686-linux with -std=c99 -O -msse2 -mfpmath=387 -march=i386. Does not fail for x86_64-linux target with -m32 on x86_64-linux _and_ i686-linux hosts. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37544
[Bug fortran/35680] [4.3/4.4 regression] ICE on invalid transfer in variable declaration
--- Comment #5 from pault at gcc dot gnu dot org 2008-09-17 08:55 --- (In reply to comment #4) 4.3.2 is released, changing milestones to 4.3.3. Although this passes Lahey with only a warning that the return value is not set, it manifestly is standard defying according to 7.1.6.2 A variable in a specification expression shall have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, or by the implicit typing rules in effect for the scoping unit, or by host or use association. If a variable in a specification expression is typed by the implicit typing rules, its appearance in any subsequent type declaration statement shall confirm the implied type and type parameters. Inverting the order of the declarations should make the code legal. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35680
[Bug middle-end/37491] [4.4 Regression] Revision 140257 causes vectorizer tests failures
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-09-17 10:10 --- The problem in PR37385 is that we do not look at the canonical type in get_alias_set, so we end up with a different alias set for the typedef (which makes the behavior of get_alias_set inconsistent with the middle-end type-system). I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-09-14 07:00:50 |2008-09-17 10:10:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37491
[Bug c++/37540] [4.4 regression] ICE on __decltype of method call in function template
--- Comment #3 from jakub at gcc dot gnu dot org 2008-09-17 10:28 --- Caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=138843 Any reason why you look at CALL_EXPR_FN's type instead of just TREE_TYPE (expr)? In this case TREE_TYPE (expr) is int, but CALL_EXPR_FN is COMPONENT_REF with NULL TREE_TYPE, created by: 5692 if (processing_template_decl call != error_mark_node) 5693call = (build_min_non_dep_call_list 5694(call, 5695 build_min_nt (COMPONENT_REF, orig_instance, orig_fns, NULL_TREE), 5696 orig_args)); -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||dgregor at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37540
[Bug c++/37552] [4.4 regression] ICE with invalid array access
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-17 10:32:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37552
[Bug rtl-optimization/37544] [4.2/4.3/4.4 Regression] Conversion double - unsigned long long - unsigned - double gives wrong results
--- Comment #8 from ubizjak at gmail dot com 2008-09-17 10:39 --- The problem is in regrename.c, function maybe_mode_change. We enter the function with: orig_mode = DImode copy_mode = SImode new_mode = DImode At the beginning of maybe_mode_change() we have: if (orig_mode == new_mode) return gen_rtx_raw_REG (new_mode, regno); we simply discard the change to a narrower mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37544
[Bug ada/37309] Ada tasking is not implemented on NetBSD
--- Comment #2 from sam at gcc dot gnu dot org 2008-09-17 11:06 --- You should sent a patch against the latest SVN trunk, so that it can be reviewed. -- sam at gcc dot gnu dot org changed: What|Removed |Added CC||sam at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37309
[Bug middle-end/37385] [4.4 Regression] ICE in set_mem_alias_set with the vectorizer and function pointers
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-09-17 11:43 --- Subject: Bug 37385 Author: rguenth Date: Wed Sep 17 11:42:11 2008 New Revision: 140412 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140412 Log: 2008-09-17 Richard Guenther [EMAIL PROTECTED] PR middle-end/37385 PR tree-optimization/37491 * alias.c (get_alias_set): Use the canonical type. * tree-vect-transform.c (vectorizable_store): Use the type of the lhs for the vector type. Adjust checking. (vectorizable_load): Adjust checking. Modified: trunk/gcc/ChangeLog trunk/gcc/alias.c trunk/gcc/tree-vect-transform.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37385
[Bug middle-end/37491] [4.4 Regression] Revision 140257 causes vectorizer tests failures
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-09-17 11:43 --- Subject: Bug 37491 Author: rguenth Date: Wed Sep 17 11:42:11 2008 New Revision: 140412 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140412 Log: 2008-09-17 Richard Guenther [EMAIL PROTECTED] PR middle-end/37385 PR tree-optimization/37491 * alias.c (get_alias_set): Use the canonical type. * tree-vect-transform.c (vectorizable_store): Use the type of the lhs for the vector type. Adjust checking. (vectorizable_load): Adjust checking. Modified: trunk/gcc/ChangeLog trunk/gcc/alias.c trunk/gcc/tree-vect-transform.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37491
[Bug fortran/37545] impossible to link with -fopenmp
--- Comment #6 from brian at dessent dot net 2008-09-17 11:44 --- Subject: Re: impossible to link with -fopenmp If you can't change your glibc version then you need to build gfortran yourself from source. The problem is that the person that is building the gfortran binary packages on the Wiki has a newer version of glibc than you do, and the configure script accordingly detects and enables the use of the newer glibc features. If you try to use it with an older glibc it will fail because they don't exist, but if you built it yourself from source it won't detect and enable the use of those features. This is a general problem with relying on binary packages that are not part of a distro (which has control over all versions.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37545
[Bug rtl-optimization/37544] [4.4 Regression] Conversion double - unsigned long long - unsigned - double gives wrong results
--- Comment #9 from ubizjak at gmail dot com 2008-09-17 11:48 --- 4.2 and 4.3 work OK. -- ubizjak at gmail dot com changed: What|Removed |Added Known to work||4.2.4 4.3.3 Summary|[4.2/4.3/4.4 Regression]|[4.4 Regression] Conversion |Conversion double -|double - unsigned long long |unsigned long long - |- unsigned - double gives |unsigned - double gives|wrong results |wrong results | Target Milestone|4.2.5 |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37544
[Bug middle-end/37491] [4.4 Regression] Revision 140257 causes vectorizer tests failures
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-09-17 11:43 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37491
[Bug fortran/35770] implicit character(s) hides type of internal function
--- Comment #4 from domob at gcc dot gnu dot org 2008-09-17 11:57 --- Subject: Bug 35770 Author: domob Date: Wed Sep 17 11:56:09 2008 New Revision: 140413 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140413 Log: 2008-09-13 Daniel Kraft [EMAIL PROTECTED] PR fortran/35770 * primary.c (gfc_match_varspec): Added missing type-spec clearing after wrong implicit character typing. 2008-09-13 Daniel Kraft [EMAIL PROTECTED] PR fortran/35770 * gfortran.dg/implicit_12.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/implicit_12.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/primary.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35770
[Bug fortran/35770] implicit character(s) hides type of internal function
--- Comment #5 from domob at gcc dot gnu dot org 2008-09-17 11:59 --- Fixed for trunk (4.4) and 4.3. -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35770
[Bug rtl-optimization/37544] [4.4 Regression] Conversion double - unsigned long long - unsigned - double gives wrong results
--- Comment #10 from ubizjak at gmail dot com 2008-09-17 12:01 ---
I'm testing following patch:
Index: regrename.c
===
--- regrename.c (revision 140409)
+++ regrename.c (working copy)
@@ -1314,6 +1314,9 @@
enum machine_mode new_mode, unsigned int regno,
unsigned int copy_regno ATTRIBUTE_UNUSED)
{
+ if (GET_MODE_SIZE (copy_mode) GET_MODE_SIZE (new_mode))
+return NULL_RTX;
+
if (orig_mode == new_mode)
return gen_rtx_raw_REG (new_mode, regno);
else if (mode_change_ok (orig_mode, new_mode, regno))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37544
[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5
--- Comment #35 from dje at gcc dot gnu dot org 2008-09-17 12:22 --- User reports successful resolution. -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37057
[Bug bootstrap/37441] [4.4 regression] dwarf2 unwind info patches produce undefined symbols
--- Comment #6 from ro at gcc dot gnu dot org 2008-09-17 12:28 --- Fixed for 4.4.0. -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37441
[Bug bootstrap/37441] [4.4 regression] dwarf2 unwind info patches produce undefined symbols
--- Comment #7 from ro at gcc dot gnu dot org 2008-09-17 12:28 --- Subject: Bug 37441 Author: ro Date: Wed Sep 17 12:26:43 2008 New Revision: 140417 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140417 Log: PR bootstrap/37441 * dwarf2out.c (dwarf2out_do_cfi_asm) [MIPS_DEBUGGING_INFO]: Return false. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37441
[Bug c++/37558] New: rev 140120 changes the accessibility of a friend decl.
Gcc 4.4 used to accept the program
---
class Foo {
friend class Bar;
friend void func(const class Bar*);
};
--
since 140120 it does not.
Simon found the following:
gcc 2.95.3, 3.4.5 and icc accept it. Previous versions of 4.4 reject it.
The standard says
11.4-7: A name nominated by a friend declaration shall be accessible in the
scope of the class containing the friend declaration...
I am not sure if we should accept or reject it, but we should have a testcase
once we decide.
--
Summary: rev 140120 changes the accessibility of a friend decl.
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: espindola at google dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37558
[Bug c++/37559] New: pow() function outputs NaN in debug build
When I compile and run the following code in my debug build using GCC 4.0.1 on an Intel Mac (OSX10.5) I find that the pow() function returns NaN whereas in the release build it works as expected. When using the powf() function it works as expected. const float dBgain = -2.75750828f; const double A = pow((float)10,(float)(dBgain/20.0))); The command line used to compile the code is as follows: CompileC build/C2 Project XCode.build/Imported CodeWarrior Settings/C2 AU Debug.build/Objects-normal/i386/CAFilterBiquad.o /Users/john/Documents/Dev/C2/Libraries/CAEffects/CAFilterBiquad.cpp normal i386 c++ com.apple.compilers.gcc.4_0 cd /Users/john/Documents/Dev/C2 /Developer/usr/bin/gcc-4.0 -x c++ -arch i386 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -gstabs+ -fno-eliminate-unused-debug-symbols -O0 -fwritable-strings -DDEBUG=1 -fmessage-length=0 -msse3 -fvisibility-inlines-hidden -mmacosx-version-min=10.4 -I/Users/john/Documents/Dev/C2/build/C2 Project XCode.build/Imported CodeWarrior Settings/C2 AU Debug.build/Alchemy.hmap -Wmost -Wno-four-char-constants -Wno-unknown-pragmas -F/Users/john/Documents/Dev/C2/build/Imported CodeWarrior Settings -F/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks -F/Users/john/Documents/Dev/C2 -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/dtrace -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/i686-apple-darwin9 -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/java -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/powerpc-apple-darwin9 -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/samba -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/sqlite3 -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/system -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/darwin -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple-darwin9 -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/powerpc-apple-darwin9 -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/i686-apple-darwin9/4.0.1 -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/powerpc-apple-darwin9/4.0.1 -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/samba/auth -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/samba/charset -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/samba/idmap -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/samba/nss_info -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/samba/pdb -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/samba/vfs -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/darwin/3.3 -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple-darwin9/4.0.1 -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/powerpc-apple-darwin9/4.0.1 -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple-darwin9/4.0.1/include -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple-darwin9/4.0.1/install-tools -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple-darwin9/4.0.1/x86_64 -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/powerpc-apple-darwin9/4.0.1/include -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/powerpc-apple-darwin9/4.0.1/install-tools -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/powerpc-apple-darwin9/4.0.1/ppc64 -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple-darwin9/4.0.1/include/c++ -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple-darwin9/4.0.1/include/pexpert -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple-darwin9/4.0.1/include/root -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple-darwin9/4.0.1/include/X11 -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple-darwin9/4.0.1/install-tools/include -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/powerpc-apple-darwin9/4.0.1/include/c++ -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/powerpc-apple-darwin9/4.0.1/install-tools/include -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple-darwin9/4.0.1/include/c++/4.0.0 -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple-darwin9/4.0.1/include/root/usr -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple-darwin9/4.0.1/include/X11/Xtrans -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/powerpc-apple-darwin9/4.0.1/include/c++/4.0.0 -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple-darwin9/4.0.1/include/root/usr/X11 -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple-darwin9/4.0.1/include/root/usr/X11/include -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple-darwin9/4.0.1/include/root/usr/X11/include/X11 -I/Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple-darwin9/4.0.1/include/root/usr/X11/include/X11/Xtrans -I/Users/john/Documents/Dev/C2/build/Imported CodeWarrior Settings/include -I/Developer/SDKs/MacOSX10.5.sdk/usr/include -I/Developer/SDKs/MacOSX10.5.sdk/Developer/Headers/FlatCarbon -ILibrary/CAAnalyser/Loris -ILibrary/CACore -ILibrary/CAGui -ILibrary/CAUtil -ILibrary/CAEffects -ILibrary/CASynthesis -ILibrary/FFT -ILibrary/CAMath -ILibrary/CAAnalyser -I/Users/john/Documents/Dev/C2/build/C2 Project XCode.build/Imported CodeWarrior Settings/C2 AU Debug.build/DerivedSources -isysroot /Developer/SDKs/MacOSX10.5.sdk -include /Users/john/Documents/Dev/C2/C2/C2AU_debug.h -c
[Bug tree-optimization/37102] [4.3/4.4 Regression] out-of-SSA is broken
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-09-17 14:25
---
Ok, so I think we should be fine if we ignore PHI nodes with zero-use results
during building the elimination graph - chained unused PHIs will have lifeness
computed for all but the PHI node with the zero-use result.
So, on the 4.3 branch the following fixes the failure for me:
Index: tree-outof-ssa.c
===
*** tree-outof-ssa.c(revision 140417)
--- tree-outof-ssa.c(working copy)
*** eliminate_build (elim_graph g, basic_blo
*** 321,326
--- 321,329
for (phi = phi_nodes (B); phi; phi = PHI_CHAIN (phi))
{
+ if (has_zero_uses (PHI_RESULT (phi)))
+ continue;
+
T0 = var_to_partition_to_var (g-map, PHI_RESULT (phi));
/* Ignore results which are not in partitions. */
I am now giving this testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37102
[Bug c++/37555] [4.2/4.3/4.4 regression] ICE with invalid typedef
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37555
[Bug c++/37554] [4.3/4.4 regression] ICE with invalid cast
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37554
[Bug c/37560] New: bitfield not promoted to int
In the following program, the type of the assignment expression f.x = 1
should be int, according to the integer promotion rules.
However, gcc 4.xx (on all architectures I've tested) prints 1.
#include stdio.h
int main()
{
struct foo { int x:1; } f;
printf(%u\n, sizeof(f.x = 1));
return 0;
}
--
Summary: bitfield not promoted to int
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: clemens at ladisch dot de
GCC target triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37560
[Bug tree-optimization/37102] [4.3/4.4 Regression] out-of-SSA is broken
--- Comment #13 from amacleod at redhat dot com 2008-09-17 14:34 --- I was in the middle of updating this PR and taking possesion :-) Upon further reflection, I don't think it is acceptable for out-of-ssa to generate incorrect code simply because an optimization wasn't run before it. So, there are 2 basic choices. ONnis as you state, only there is an additional bit required during the rewrite verification. The other option is a very mini dead phi removal done at the same time as virtual phis are eliminated. its only a few lines of code and simple removes PHIs with no uses, and takes care of the ripple effect as well. I have a patch for it as well, its just not completely tested yet. I'll attach both in a minute, I just wanted you to know I was looking at it :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37102
[Bug middle-end/36747] ICE in set_uids_in_ptset, at tree-ssa-structalias.c:4785 with -O
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-17 14:34 --- *** Bug 37310 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||petermorgan at grapevine dot ||net dot au http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36747
[Bug tree-optimization/37310] [4.3 Regression] gfortran errors in compilation and the making for upgraded compilers
--- Comment #17 from rguenth at gcc dot gnu dot org 2008-09-17 14:34 --- I think this is a duplicate of PR36747 as I no longer can reporduce this with 4.3.2. *** This bug has been marked as a duplicate of 36747 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to fail|4.2.0 |4.2.0 4.3.1 Known to work|4.4.0 |4.4.0 4.3.2 Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37310
[Bug tree-optimization/37102] [4.3/4.4 Regression] out-of-SSA is broken
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-09-17 14:38 --- Hm, it doesn't work - bootstrap fails as gengtype segfaults. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37102
[Bug tree-optimization/37102] [4.3/4.4 Regression] out-of-SSA is broken
--- Comment #15 from amacleod at redhat dot com 2008-09-17 14:39 --- Created an attachment (id=16343) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16343action=view) potential patch 1 This is the first option which simply doesn't add the result of a PHI with no uses to the partition map. It passes bootstrap and all tests on x86_64-unknown-linux-gnu with no regressions. -- amacleod at redhat dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amacleod at redhat dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37102
[Bug c++/37260] [4.1/4.2/4.3 Regression] infinite loop in init
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37260
[Bug tree-optimization/36343] [4.3 Regression] Wrong code due to bad TBAA pruning of points-to-sets and use in call clobbering
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-09-17 14:46 --- Created an attachment (id=16344) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16344action=view) patch disabling TBAA pruning This is the patch we use for openSUSE to fix this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36343
[Bug tree-optimization/37102] [4.3/4.4 Regression] out-of-SSA is broken
--- Comment #16 from amacleod at redhat dot com 2008-09-17 14:48 --- Created an attachment (id=16345) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16345action=view) Potential patch #2 This is the other option, eliminate dead PHIs. compiling all of GCC .c files at -O3, it finds a total of 12 instances of dead phis, and 3 of those were extra ones made dead by elimination of the original dead PHI. This patch has not yet been bootstrapped and fully tested, its ongoing now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37102
[Bug testsuite/37561] New: [4.4 Regression] Revision 140405 caused g++.old-deja/g++.mike/warn1.C
bash-3.2$ cat g++.old-deja/g++.mike/warn1.C
// { dg-do assemble }
// { dg-options -Wall }
typedef char * charptr;
typedef __SIZE_TYPE__ size_t;
char c[]={'A','B','C','D'};
int i=size_t(c);
int *pp=i;
void foo() { }
int main()
{
charptr(*pp)++;// { dg-warning }
return 0;
}
bash-3.2$ gcc -Wall -S -o /tmp/x.s g++.old-deja/g++.mike/warn1.C -m64
g++.old-deja/g++.mike/warn1.C: In function âint main()â:
g++.old-deja/g++.mike/warn1.C:12: warning: value computed is not used
bash-3.2$ gcc -Wall -S -o /tmp/x.s g++.old-deja/g++.mike/warn1.C -m32
g++.old-deja/g++.mike/warn1.C: In function âint main()â:
g++.old-deja/g++.mike/warn1.C:12: error: lvalue required as increment operand
bash-3.2$
On Linux/x86-64, I got
FAIL: g++.old-deja/g++.mike/warn1.C (test for errors, line 12)
FAIL: g++.old-deja/g++.mike/warn1.C (test for excess errors)
--
Summary: [4.4 Regression] Revision 140405 caused g++.old-
deja/g++.mike/warn1.C
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37561
[Bug c/37560] bitfield not promoted to int
--- Comment #1 from joseph at codesourcery dot com 2008-09-17 14:50 --- Subject: Re: New: bitfield not promoted to int On Wed, 17 Sep 2008, clemens at ladisch dot de wrote: In the following program, the type of the assignment expression f.x = 1 should be int, according to the integer promotion rules. However, gcc 4.xx (on all architectures I've tested) prints 1. Why do you think the type should be int instead of int:1? The conclusion from C90 DRs was that bit-fields have their own types, and from C99 DRs was to leave whether they have their own types implementation-defined, and GCC follows the C90 DRs and so the assignment has type int:1 and is not promoted as an operand of sizeof. Now, for C++ you have a valid bug report, since there bit-fields do not have their own types, and the reported behavior appears for C++ as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37560
[Bug middle-end/18071] [4.2/4.3/4.4 Regression] -Winline does not respect -fno-default-inline
--- Comment #37 from hubicka at gcc dot gnu dot org 2008-09-17 15:02 --- Subject: Bug 18071 Author: hubicka Date: Wed Sep 17 15:00:59 2008 New Revision: 140418 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140418 Log: PR c++/18071 * tree.h (DECL_INLINE): remove. (DECL_DECLARED_INLINE_P): Update docs. (DECL_NO_INLINE_WARNING_P): new. (tree_function_decl): Replace inline_flag by no_inline_warning_flag. * tree-inline.c (inlinable_function_p): Set DECL_NO_INLINE_WARNING_P. Java: * class.c (add_method_1): Do not initialize DECL_INLINE. (make_local_function_alias): Likewise. * expr.c (rewrite_arglist_getcaller): Set DECL_UNINLINABLE. * lang.c (java_decl_ok_for_sibcall): Use DECL_UNINLINABLE. Objc: * objc/objc-act.c (objc_finish_method_definition): Do not set DECL_INLINE. C++: * cp/decl.c (start_method): Set DECL_NO_INLINE_WARNING_P. Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/java/ChangeLog trunk/gcc/java/class.c trunk/gcc/java/expr.c trunk/gcc/java/lang.c trunk/gcc/objc/ChangeLog trunk/gcc/objc/objc-act.c trunk/gcc/tree-inline.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
[Bug tree-optimization/36343] [4.3 Regression] Wrong code due to bad TBAA pruning of points-to-sets and use in call clobbering
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2008-09-17 15:07 --- This is the patch we use for openSUSE to fix this bug. Any particular reason for not installing it at the FSF as well? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36343
[Bug tree-optimization/36343] [4.3 Regression] Wrong code due to bad TBAA pruning of points-to-sets and use in call clobbering
--- Comment #8 from rguenther at suse dot de 2008-09-17 15:10 --- Subject: Re: [4.3 Regression] Wrong code due to bad TBAA pruning of points-to-sets and use in call clobbering On Wed, 17 Sep 2008, ebotcazou at gcc dot gnu dot org wrote: --- Comment #7 from ebotcazou at gcc dot gnu dot org 2008-09-17 15:07 --- This is the patch we use for openSUSE to fix this bug. Any particular reason for not installing it at the FSF as well? It disables optimizations and the testcase was artificially created by me from looking at the source. But let me just submit the patch (again) and ask for feedback. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36343
[Bug c/37560] bitfield not promoted to int
--- Comment #2 from clemens at ladisch dot de 2008-09-17 15:11 --- According to the proposed TC in DR 315 (If an int can represent all values of the original type (as restricted by the width, for a bit-field), the type is converted to an int;), -- clemens at ladisch dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37560
[Bug tree-optimization/37525] [4.4 Regression] IVOPTS difference causing 20% degradation in 173.applu benchmark
--- Comment #1 from jakub at gcc dot gnu dot org 2008-09-17 15:12 --- I guess the problem might be that Fortran has signed size_type_node (and unsigned sizetype), so what the newly added code in int_fits_type_p does breaks Fortran assumptions. Say for sizetype -25 (i.e. unsigned value), when it is force_fit_type_double into a signed type, it becomes signed -25, and given that type_low_bound (of sizetype) is 0 and -25 is smaller than 0, int_fits_type_p fails. Perhaps just adding another TYPE_UNSIGNED (size_type_node) check to the if would be sufficient. That said, I still think such change isn't appropriate for 4.3 branch. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||dodji at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37525
[Bug tree-optimization/37508] [4.4 Regression] ICE in in simplify_truth_ops_using_ranges, at tree-vrp.c:6334
--- Comment #7 from bonzini at gnu dot org 2008-09-17 15:17 --- Do you have a missed optimization for optimizing the functions to return 1? Or does your patch fix it too? -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37508
[Bug c++/37559] pow() function outputs NaN in debug build
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-17 15:19 --- GCC 4.0.1 is no longer supported by the FSF. Please update to at least GCC 4.2.4 and re-check if the problem is fixed. You may also want to report to Apple instead which is known to heavily modify their compilers. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37559
[Bug fortran/37536] [4.3/4.4 Regression] a mfcr is produced instead of branches for DO loops
--- Comment #9 from luisgpm at linux dot vnet dot ibm dot com 2008-09-17 15:22 --- Gathered some PPC 32/64 performance numbers with the patch (based on 140409). No noticeable performance regressions were found. 32-bit swin and 64-bit art had a little boost on speed (7.8% and 3.4% respectivelly). -- luisgpm at linux dot vnet dot ibm dot com changed: What|Removed |Added CC||luisgpm at linux dot vnet ||dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37536
[Bug tree-optimization/37508] [4.4 Regression] ICE in in simplify_truth_ops_using_ranges, at tree-vrp.c:6334
--- Comment #8 from rguenther at suse dot de 2008-09-17 15:24 --- Subject: Re: [4.4 Regression] ICE in in simplify_truth_ops_using_ranges, at tree-vrp.c:6334 On Wed, 17 Sep 2008, bonzini at gnu dot org wrote: --- Comment #7 from bonzini at gnu dot org 2008-09-17 15:17 --- Do you have a missed optimization for optimizing the functions to return 1? Or does your patch fix it too? See PR37541. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37508
[Bug inline-asm/37562] New: [4.2] -funroll-loops destroys inline asm code von powerpc
typedef unsigned int UInt32;
typedef unsigned char UInt8;
struct Data
{
UInt8 data[16];
const UInt8* getData() const
{
return data + 4;
}
};
struct Value {
UInt32 value;
static void update (Value signal, const Data source, UInt32 startBit);
};
void Value::update(Value signal, const Data source, UInt32 startByte)
{
UInt32 value = signal.value;
const UInt8* data = source.getData();
asm( lwbrx %0,%1,%2;\n:=r(value): r(data), r(startByte), m (*(data
+ startByte)) );
}
generated for gcc-4.2.4 on powerpc:
_ZN5Value6updateERS_RK4Dataj:
0: 38 04 00 04 addir0,r4,4
4: 7c 80 2c 2c lwbrx r4,0,r5
8: 90 83 00 00 stw r4,0(r3)
c: 4e 80 00 20 blr
the correct version without -funroll-loops reads:
_ZN5Value6updateERS_RK4Dataj:
0: 38 84 00 04 addir4,r4,4
4: 7c 84 2c 2c lwbrx r4,r4,r5
8: 90 83 00 00 stw r4,0(r3)
c: 4e 80 00 20 blr
lwbrx sums the contents of r4 and r5 and accesses this address, swaps it's
value and stores it again in r4. The incorrect version accesses an invalid
address, which leads to a segmentation fault.
this is corrected at least with gcc-4.3.1, there i couldn't reproduce the
behaviour.
--
Summary: [4.2] -funroll-loops destroys inline asm code von
powerpc
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rbuergel at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37562
[Bug inline-asm/37562] [4.2] -funroll-loops destroys inline asm code von powerpc
--- Comment #1 from rbuergel at web dot de 2008-09-17 15:44 --- oops, i forgot to mention my command line to compile it: powerpc-linux-g++ -O3 -funroll-loops -c -o GetBytes2.o GetBytes2.cpp using -O3 is important for reproducing this error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37562
[Bug c/37560] bitfield not promoted to int
--- Comment #3 from joseph at codesourcery dot com 2008-09-17 15:55 --- Subject: Re: bitfield not promoted to int On Wed, 17 Sep 2008, clemens at ladisch dot de wrote: According to the proposed TC in DR 315 (If an int can represent all values of the original type (as restricted by the width, for a bit-field), the type is converted to an int;), That's part of the integer promotions, which are only applied in certain contexts (and the operand of sizeof is not one of those contexts). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37560
[Bug testsuite/37561] [4.4 Regression] Revision 140405 caused g++.old-deja/g++.mike/warn1.C
--- Comment #1 from janis at gcc dot gnu dot org 2008-09-17 16:00 ---
I tested with -m32 on powerpc64-linux, not with both -m32/-m64 which would have
caught this; I'll test with both for related patches.
The test previously used { dg-warning }, which matched any message from that
line. The patch, in preparation to using new versions of dg-error and
dg-warning that actually check for warning and error, changed that to {
dg-error lvalue }, which matches the error message for -m32 but not the
warning message for -m64. It's a bug in the compiler that the error isn't
reported for -m64, and the change to the test merely detected that.
This should be a C++ bug, not a testsuite bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37561
[Bug c++/37563] New: [4.3/4.4 regression] Trouble calling qualified member function
The following valid code snippet is rejected since GCC 4.3.0:
==
struct A {};
templateint struct Traits
{
typedef void X;
};
template struct Traits0
{
typedef A X;
};
templateint N struct B
{
typedef typename TraitsN::X Y;
void foo(Y y)
{
y.Y::A::~A();
}
};
==
bug.cc: In member function 'void BN::foo(typename TraitsN::X)':
bug.cc:19: error: 'void' is not a class type
--
Summary: [4.3/4.4 regression] Trouble calling qualified member
function
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37563
[Bug c++/37563] [4.3/4.4 regression] Trouble calling qualified member function
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37563
[Bug libfortran/37564] New: collect2: ld returned 1 exit status make[3]: *** [libgfortran.la] Error 1
Hello, From the terminal, I many lines that look similar to: .libs/in_unpack_generic.o(.text+0x820): In function `getline': /usr/include/bits/stdio.h:103: multiple definition of `getline' .libs/backtrace.o(.text+0xbc0):/usr/include/bits/stdio.h:103: first defined here .libs/in_unpack_generic.o(.text+0x830): In function `putchar_unlocked': /usr/include/bits/stdio.h:94: multiple definition of `putchar_unlocked' .libs/backtrace.o(.text+0xbd0):/usr/include/bits/stdio.h:94: first defined here ... ... ... After that terminal output says: collect2: ld returned 1 exit status make[3]: *** [libgfortran.la] Error 1 make[3]: Leaving directory `/home/rkraft/apps/gcc-4.3.1/x86_64-unknown-linux-gnu/libgfortran' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/rkraft/apps/gcc-4.3.1/x86_64-unknown-linux-gnu/libgfortran' make[1]: *** [all-target-libgfortran] Error 2 make[1]: Leaving directory `/home/rkraft/apps/gcc-4.3.1' make: *** [all] Error 2 I get this same error for gcc4.3.2 also. What cause this and how do I fix it? Configure log from x86_64-unknown-linux-gnu/libgfortran/ attached. Thanks for your time. -- Summary: collect2: ld returned 1 exit status make[3]: *** [libgfortran.la] Error 1 Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reuben dot kraft at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37564
[Bug libfortran/37564] collect2: ld returned 1 exit status make[3]: *** [libgfortran.la] Error 1
--- Comment #1 from reuben dot kraft at gmail dot com 2008-09-17 16:04 --- Created an attachment (id=16346) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16346action=view) x86_64-unknown-linux-gnu/libgfortran/config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37564
[Bug preprocessor/37324] [4.4 Regression] FAIL: gcc.dg/utf-array.c (test for errors)
--- Comment #3 from jakub at gcc dot gnu dot org 2008-09-17 16:06 ---
Subject: Bug 37324
Author: jakub
Date: Wed Sep 17 16:05:11 2008
New Revision: 140421
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140421
Log:
PR preprocessor/37324
* lib/target-supports.exp
(check_effective_target_wchar_t_char16_t_compatible,
check_effective_target_wchar_t_char32_t_compatible): New.
* gcc.dg/utf-array.c: Use __CHAR{16,32}_TYPE__ macros in typedefs.
Only require from incompatible errors for char{16,32}_t vs. wchar_t
initializations if those types are indeed incompatible.
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/utf-array.c
trunk/gcc/testsuite/lib/target-supports.exp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37324
[Bug preprocessor/37324] [4.4 Regression] FAIL: gcc.dg/utf-array.c (test for errors)
--- Comment #4 from jakub at gcc dot gnu dot org 2008-09-17 16:07 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37324
[Bug c++/37552] [4.4 regression] ICE with invalid array access
--- Comment #1 from jakub at gcc dot gnu dot org 2008-09-17 16:08 --- Subject: Bug 37552 Author: jakub Date: Wed Sep 17 16:07:08 2008 New Revision: 140422 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140422 Log: PR c++/37552 * typeck.c (build_array_ref): Use protected_set_expr_location instead of SET_EXPR_LOCATION when ret might not be an expression. * g++.dg/parse/crash49.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/crash49.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37552
[Bug c++/37552] [4.4 regression] ICE with invalid array access
--- Comment #2 from jakub at gcc dot gnu dot org 2008-09-17 16:10 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37552
[Bug testsuite/37561] [4.4 Regression] Revision 140405 caused g++.old-deja/g++.mike/warn1.C
--- Comment #2 from hjl dot tools at gmail dot com 2008-09-17 16:11 ---
(In reply to comment #1)
I tested with -m32 on powerpc64-linux, not with both -m32/-m64 which would
have
caught this; I'll test with both for related patches.
The test previously used { dg-warning }, which matched any message from
that
line. The patch, in preparation to using new versions of dg-error and
dg-warning that actually check for warning and error, changed that to {
dg-error lvalue }, which matches the error message for -m32 but not the
warning message for -m64. It's a bug in the compiler that the error isn't
reported for -m64, and the change to the test merely detected that.
This should be a C++ bug, not a testsuite bug.
I am not sure if it is a C++ bug. The differences between -m32
and -m64 are the sizes of __SIZE_TYPE__, int and pointer. Replace
int with long gives me
[EMAIL PROTECTED] tmp]$ cat x.cc
typedef char * charptr;
typedef __SIZE_TYPE__ size_t;
char c[]={'A','B','C','D'};
long i=size_t(c);
long *pp=i;
void foo() { }
int main()
{
charptr(*pp)++;// { dg-warning }
return 0;
}
[EMAIL PROTECTED] tmp]$ gcc -Wall x.cc -S -m64
x.cc: In function âint main()â:
x.cc:9: error: lvalue required as increment operand
[EMAIL PROTECTED] tmp]$ gcc -Wall x.cc -S -m32
x.cc: In function âint main()â:
x.cc:9: error: lvalue required as increment operand
[EMAIL PROTECTED] tmp]$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37561
[Bug c++/37439] ICE using auto return-type in template function
--- Comment #1 from jason at gcc dot gnu dot org 2008-09-17 16:12 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37439
[Bug c++/37302] function parameters are declared too late
--- Comment #1 from jason at gcc dot gnu dot org 2008-09-17 16:13 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37302
[Bug rtl-optimization/37544] [4.4 Regression] Conversion double - unsigned long long - unsigned - double gives wrong results
--- Comment #11 from ubizjak at gmail dot com 2008-09-17 16:13 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01221.html -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||09/msg01221.html Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2008-09-16 19:17:21 |2008-09-17 16:13:33 date|| Target Milestone|4.3.4 |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37544
[Bug c++/37208] C++0x deleted functions and SFINAE
--- Comment #4 from jason at gcc dot gnu dot org 2008-09-17 16:14 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37208
[Bug c++/37558] [4.4 regression] rev 140120 changes the accessibility of a friend decl.
--- Comment #1 from jason at gcc dot gnu dot org 2008-09-17 16:19 --- This doesn't have anything to do with accessibility, but it is a new bug. -- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Priority|P3 |P1 Last reconfirmed|-00-00 00:00:00 |2008-09-17 16:19:57 date|| Summary|rev 140120 changes the |[4.4 regression] rev 140120 |accessibility of a friend |changes the accessibility of |decl. |a friend decl. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37558
Re: [Bug inline-asm/37562] New: [4.2] -funroll-loops destroys inline asm code von powerpc
Sent from my iPhone
On Sep 17, 2008, at 8:42 AM, rbuergel at web dot de [EMAIL PROTECTED]
wrote:
typedef unsigned int UInt32;
typedef unsigned char UInt8;
struct Data
{
UInt8 data[16];
const UInt8* getData() const
{
return data + 4;
}
};
struct Value {
UInt32 value;
static void update (Value signal, const Data source, UInt32
startBit);
};
void Value::update(Value signal, const Data source, UInt32
startByte)
{
UInt32 value = signal.value;
const UInt8* data = source.getData();
asm( lwbrx %0,%1,%2;\n:=r(value): r(data), r(startByte),
m (*(data
+ startByte)) );
}
The second constraint should be using b instead of r as b says
don't use r0.
generated for gcc-4.2.4 on powerpc:
_ZN5Value6updateERS_RK4Dataj:
0: 38 04 00 04 addir0,r4,4
4: 7c 80 2c 2c lwbrx r4,0,r5
8: 90 83 00 00 stw r4,0(r3)
c: 4e 80 00 20 blr
the correct version without -funroll-loops reads:
_ZN5Value6updateERS_RK4Dataj:
0: 38 84 00 04 addir4,r4,4
4: 7c 84 2c 2c lwbrx r4,r4,r5
8: 90 83 00 00 stw r4,0(r3)
c: 4e 80 00 20 blr
lwbrx sums the contents of r4 and r5 and accesses this address,
swaps it's
value and stores it again in r4. The incorrect version accesses an
invalid
address, which leads to a segmentation fault.
this is corrected at least with gcc-4.3.1, there i couldn't
reproduce the
behaviour.
--
Summary: [4.2] -funroll-loops destroys inline asm code von
powerpc
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rbuergel at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37562
[Bug inline-asm/37562] [4.2] -funroll-loops destroys inline asm code for powerpc
--- Comment #2 from pinskia at gmail dot com 2008-09-17 16:52 ---
Subject: Re: New: [4.2] -funroll-loops destroys inline asm code von powerpc
Sent from my iPhone
On Sep 17, 2008, at 8:42 AM, rbuergel at web dot de [EMAIL PROTECTED]
wrote:
typedef unsigned int UInt32;
typedef unsigned char UInt8;
struct Data
{
UInt8 data[16];
const UInt8* getData() const
{
return data + 4;
}
};
struct Value {
UInt32 value;
static void update (Value signal, const Data source, UInt32
startBit);
};
void Value::update(Value signal, const Data source, UInt32
startByte)
{
UInt32 value = signal.value;
const UInt8* data = source.getData();
asm( lwbrx %0,%1,%2;\n:=r(value): r(data), r(startByte),
m (*(data
+ startByte)) );
}
The second constraint should be using b instead of r as b says
don't use r0.
generated for gcc-4.2.4 on powerpc:
_ZN5Value6updateERS_RK4Dataj:
0: 38 04 00 04 addir0,r4,4
4: 7c 80 2c 2c lwbrx r4,0,r5
8: 90 83 00 00 stw r4,0(r3)
c: 4e 80 00 20 blr
the correct version without -funroll-loops reads:
_ZN5Value6updateERS_RK4Dataj:
0: 38 84 00 04 addir4,r4,4
4: 7c 84 2c 2c lwbrx r4,r4,r5
8: 90 83 00 00 stw r4,0(r3)
c: 4e 80 00 20 blr
lwbrx sums the contents of r4 and r5 and accesses this address,
swaps it's
value and stores it again in r4. The incorrect version accesses an
invalid
address, which leads to a segmentation fault.
this is corrected at least with gcc-4.3.1, there i couldn't
reproduce the
behaviour.
--
Summary: [4.2] -funroll-loops destroys inline asm code von
powerpc
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rbuergel at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37562
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37562
[Bug testsuite/37561] [4.4 Regression] Revision 140405 caused g++.old-deja/g++.mike/warn1.C
--- Comment #3 from janis at gcc dot gnu dot org 2008-09-17 17:02 ---
This is twisting my brain, but in this simplified testcase:
__PTRDIFF_TYPE__ p;
short q;
void foo () { ((char *)p)++; }
void bar () { ((char *)q)++; }
we get an error with both -m32 and-m64 for foo but not for bar:
elm3b149% /home/janis/tools/gcc-trunk-anonsvn/bin/g++ -c -m32 z.C
z.C: In function void foo():
z.C:3: error: lvalue required as increment operand
elm3b149% /home/janis/tools/gcc-trunk-anonsvn/bin/g++ -c -m64 z.C
z.C: In function void foo():
z.C:3: error: lvalue required as increment operand
although the expression (char *)q in bar is not an lvalue. What am I
missing?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37561
[Bug c++/37558] [4.4 regression] rev 140120 changes the accessibility of a friend decl.
--- Comment #2 from jason at gcc dot gnu dot org 2008-09-17 17:31 --- Fixed -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37558
[Bug libstdc++/37547] [c++0x] minmax with initializer_list gives incorrect results
--- Comment #1 from paolo dot carlini at oracle dot com 2008-09-17 17:35 --- Thanks for catching this early, apparently this is a fundamental issue with the current proposal: having such overloads returning const refs to elements of the initializer_list is a very bad idea, because the initializer_list goes away upon function return. The important point here is that when the initializer_list is build it contains a *copy* of v, not v itself, which thus goes away when the initializer_list dies. Let's fix the proposal... ;) -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-17 17:35:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37547
[Bug testsuite/37561] [4.4 Regression] Revision 140405 caused g++.old-deja/g++.mike/warn1.C
--- Comment #4 from janis at gcc dot gnu dot org 2008-09-17 17:38 --- The same thing happens in C for the simplified testcase; z.c is a copy of z.C from comment #3: elm3b149% /home/janis/tools/gcc-trunk-anonsvn/bin/gcc -c -m32 z.c z.c: In function foo: z.c:3: error: lvalue required as increment operand z.c: In function bar: z.c:4: warning: cast to pointer from integer of different size elm3b149% /home/janis/tools/gcc-trunk-anonsvn/bin/gcc -c -m64 z.c z.c: In function foo: z.c:3: error: lvalue required as increment operand z.c: In function bar: z.c:4: warning: cast to pointer from integer of different size -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37561
[Bug middle-end/37448] [4.3 Regression] gcc 4.3.1 cannot compile big function
--- Comment #13 from lucier at math dot purdue dot edu 2008-09-17 17:49 --- In the attached statistics file you find where this allocation overflowed Alloc-pool KindPools Allocated PeakLeak - df_scan_ref pool 868 -1403330584 607042176 0 which is similar to what happens in 26854, so perhaps this PR could also be improved with factored use-def chains. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
[Bug c++/37450] [4.4 Regression] C++ FE times out on duplicated parameter
--- Comment #3 from hjl at gcc dot gnu dot org 2008-09-17 17:58 --- Subject: Bug 37450 Author: hjl Date: Wed Sep 17 17:57:24 2008 New Revision: 140425 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140425 Log: 2008-09-17 H.J. Lu [EMAIL PROTECTED] PR c++/37450 * name-lookup.c (pushdecl_maybe_friend): Don't return the old parameter for duplicate. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37450
[Bug c++/37450] [4.4 Regression] C++ FE times out on duplicated parameter
--- Comment #4 from hjl dot tools at gmail dot com 2008-09-17 17:59 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37450
[Bug target/37394] [4.4 Regression] Segfault in ia64_variable_issue with -O -fschedule-insns2
--- Comment #8 from hjl dot tools at gmail dot com 2008-09-17 18:06 --- It may also impact PR 37283. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37394
[Bug inline-asm/37562] [4.2] -funroll-loops destroys inline asm code for powerpc
--- Comment #3 from rbuergel at web dot de 2008-09-17 18:46 --- The second constraint should be using b instead of r as b says don't use r0. Is this documented anywhere? The gcc manual says r means any general purpose register and b means Address base register. Any Documentation (for example http://developer.apple.com/documentation/DeveloperTools/Reference/Assembler/PPCInstructions/chapter_6_section_2.html ) i've found, lists r0-r31 as general purpose registers. Anyway, ignoring this point, you seem to be right. I remember 4.3.1 using r6 instead of r0, probably that's why it works. Unfortunately, i can't check your suggestion until monday, when i'm back at work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37562
[Bug inline-asm/37562] [4.2] -funroll-loops destroys inline asm code for powerpc
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-17 18:50 --- From: http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Machine-Constraints.html#Machine-Constraints b Address base register Address base register is the standard saying rN or 0 (if r0 is used). This is just the way PPC asm works. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37562
[Bug libfortran/37564] collect2: ld returned 1 exit status make[3]: *** [libgfortran.la] Error 1
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-17 18:53 --- Did you compile in the source directory? If so, don't. It is not well supported and it is currently known to be broken for this same reason, see PR 35619. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37564
[Bug inline-asm/37562] [4.2] -funroll-loops destroys inline asm code for powerpc
--- Comment #5 from rbuergel at web dot de 2008-09-17 18:57 --- Too bad for newbies to ppc asm. :) But thank you for your explanations -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37562
[Bug libfortran/37564] collect2: ld returned 1 exit status make[3]: *** [libgfortran.la] Error 1
--- Comment #3 from reuben dot kraft at gmail dot com 2008-09-17 19:04 --- Do you mean do not run make from gcc-4.3.1 ? Or do mean do not set prefix to gcc-4.3.1 ? Currently I run make from /home/rkraft/apps/gcc-4.3.1 and I set prefix to /home/rkraft/apps/gcc4 Here is my configure: ./configure --prefix=/home/rkraft/apps/gcc4 --with-mpfr=/home/rkraft/apps/mpfr-2.3.2 --disable-multilib --enable-languages=fortran,c,c++ --with-gmp=/home/rkraft/apps/gmp-4.2.3 --with-gmp-lib=/home/rkraft/apps/gmp-4.2.3/lib --with-mpfr-lib=/home/rkraft/apps/mpfr-2.3.2/lib: -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37564
[Bug inline-asm/37562] [4.2] -funroll-loops destroys inline asm code for powerpc
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-09-17 19:06 --- You can also use __builtin_bswap32 in GCC 4.3 and above which gives you the best code generation as it understands loading from memory and if the value is in a register already. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37562
[Bug libfortran/37564] collect2: ld returned 1 exit status make[3]: *** [libgfortran.la] Error 1
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-17 19:07 --- Please read http://gcc.gnu.org/install/configure.html: First, we highly recommend that GCC be built into a separate directory than 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. *** This bug has been marked as a duplicate of 35619 *** -- 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=37564
[Bug bootstrap/35619] [4.3/4.4 Regression] fixed includes not being found if building in src dir
--- Comment #23 from pinskia at gcc dot gnu dot org 2008-09-17 19:07 --- *** Bug 37564 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||reuben dot kraft at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35619
[Bug libfortran/37564] collect2: ld returned 1 exit status make[3]: *** [libgfortran.la] Error 1
--- Comment #5 from burnus at gcc dot gnu dot org 2008-09-17 19:08 --- Currently I run make from /home/rkraft/apps/gcc-4.3.1 Here is my configure: ./configure --prefix=/home/rkraft/apps/gcc4 Try: cd /home/rkraft/apps/ mkdir gcc-4.3.1-build cd gcc-4.3.1-build ../gcc-4.3.1/configure --prefix=/home/rkraft/apps/gcc4 \ --with-mpfr=/home/rkraft/apps/mpfr-2.3.2 --disable-multilib \ --enable-languages=fortran,c,c++ --with-gmp=/home/rkraft/apps/gmp-4.2.3 \ --with-gmp-lib=/home/rkraft/apps/gmp-4.2.3/lib \ --with-mpfr-lib=/home/rkraft/apps/mpfr-2.3.2/lib: As Andrew already wrote: You should not build in the source directory but you should build into another, empty directory like I did in the example above. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37564
[Bug c++/22374] C++ front-end produces mis-match types in MODIFY_EXPR (dynamic_cast)
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-17 19:08 --- Subject: Bug 22374 Author: rguenth Date: Wed Sep 17 19:07:27 2008 New Revision: 140427 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140427 Log: 2008-09-17 Richard Guenther [EMAIL PROTECTED] PR c++/22374 * rtti.c (build_dynamic_cast_1): Convert the COND_EXPR result to the correct type. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/rtti.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22374
[Bug c++/22374] C++ front-end produces mis-match types in MODIFY_EXPR (dynamic_cast)
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-09-17 19:08 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22374
[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
