[Bug libstdc++/31370] resizing bugs in std::vector
--- Comment #5 from pcarlini at suse dot de 2007-03-27 09:07 --- Thanks. On the mainline and 4_2-branch we have new definitions of max_size, taking into account, as should be, allocator::max_size. Can you please check the vector bits in this light? (well, about the status of vector, Andrew is overstating the issue a bit, but mostly right: we aren't that much motivated in improving it, but we have to do that anyway as long as it stays in the standard, recently we improved its performance quite a bit in a few areas). One final observation: if you feel like contributing other improvements, please consider filing the necessary Copyright Assignment paperworks: your patch will be close to the maximum we can get in as a "small contribution" under relaxed rules: http://gcc.gnu.org/contribute.html -- pcarlini at suse dot de changed: What|Removed |Added CC||pcarlini at suse dot de Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-27 09:07:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31370
[Bug fortran/30865] [4.1, 4.2 only] optional argument passed on to size(...,dim=)
--- Comment #14 from pault at gcc dot gnu dot org 2007-03-27 09:59 --- Not a regression from 4.1, so closing. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30865
[Bug target/31364] [4.3 Regression] ICE in extract_insn, at recog.c:2119 during bootstrap
--- Comment #4 from tbm at cyrius dot com 2007-03-27 09:59 --- I configured with: ../src/configure -v --enable-languages=c,c++,java,fortran,objc,obj-c++,ada,treelang --prefix=/usr/lib/gcc-snapshot --enable-shared --with-system-zlib --disable-nls --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-maintainer-mode --enable-java-awt=gtk-default --enable-gtk-cairo --enable-plugin --with-java-home=/usr/lib/gcc-snapshot/jre --with-ecj-jar=/usr/share/java/ecj.jar --enable-mpfr --disable-softfloat --enable-secureplt --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 --disable-werror powerpc-linux-gnu There is a full build log at http://buildd.debian.org/fetch.cgi?&pkg=gcc-snapshot&ver=20070326-1&arch=powerpc&stamp=1174959579&file=log Hmm, there are some locale patches. I need to check whether they cause it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31364
[Bug fortran/30882] [4.1 and 4.2 only] size with initialization expression value for dim= is rejected
--- Comment #5 from pault at gcc dot gnu dot org 2007-03-27 10:01 --- This is not a regression wrt 4.1 so closing. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30882
[Bug fortran/31011] [4.2 and 4.1 only] Incorrect error: parameter array sections
--- Comment #4 from pault at gcc dot gnu dot org 2007-03-27 10:02 --- This is not a regression wrt 4.1 so closing. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31011
[Bug fortran/30883] [4.1/4.2 only] procedure with dummy procedure f1 rejected with implicit none
--- Comment #7 from pault at gcc dot gnu dot org 2007-03-27 10:03 --- This is not a regression wrt 4.1 so closing. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30883
[Bug fortran/30870] [4.1, 4.2 only] GENERIC non-INTRINSIC procedure rejected as actual argument
--- Comment #5 from pault at gcc dot gnu dot org 2007-03-27 10:03 --- This is not a regression wrt 4.1 so closing. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30870
[Bug fortran/31163] [4.2 only] SAVEd derived types with ALLOCATABLE components don't work
--- Comment #5 from pault at gcc dot gnu dot org 2007-03-27 10:04 --- This is not a regression wrt 4.1 so closing. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31163
[Bug fortran/30879] [4.2/4.1 only] Syntax error for derived type's compounds in a data-stmt-value-set
--- Comment #4 from pault at gcc dot gnu dot org 2007-03-27 10:06 --- This is not a regression wrt 4.1 so closing. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30879
[Bug fortran/31188] [4.2 only] ICE on vector subscript of a parameter array
--- Comment #6 from pault at gcc dot gnu dot org 2007-03-27 10:06 --- This is not a regression wrt 4.1 so closing. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31188
[Bug fortran/31193] [4.2 only] ICE on non-constant character tranfert
--- Comment #5 from pault at gcc dot gnu dot org 2007-03-27 10:09 --- This is not a regression wrt 4.1 so closing. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31193
[Bug fortran/30531] [4.2 only] allocatable component and intent(out) yield ICE in fold_convert
--- Comment #12 from pault at gcc dot gnu dot org 2007-03-27 10:17 --- This is not a regression wrt to 4.1, so am clearing. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30531
[Bug fortran/31292] ICE with module procedure interface in a procedure body
--- Comment #1 from pault at gcc dot gnu dot org 2007-03-27 10:21 ---
This will be submitted this afternoon - Paul
Index: gcc/fortran/decl.c
===
*** gcc/fortran/decl.c (revision 123183)
--- gcc/fortran/decl.c (working copy)
*** gfc_match_modproc (void)
*** 4241,4246
--- 4241,4247
char name[GFC_MAX_SYMBOL_LEN + 1];
gfc_symbol *sym;
match m;
+ gfc_namespace *module_ns;
if (gfc_state_stack->state != COMP_INTERFACE
|| gfc_state_stack->previous == NULL
*** gfc_match_modproc (void)
*** 4251,4256
--- 4252,4265
return MATCH_ERROR;
}
+ module_ns = gfc_current_ns->parent;
+ for (; module_ns; module_ns = module_ns->parent)
+ if (module_ns->proc_name->attr.flavor == FL_MODULE)
+ break;
+
+ if (module_ns == NULL)
+ return MATCH_ERROR;
+
for (;;)
{
m = gfc_match_name (name);
*** gfc_match_modproc (void)
*** 4259,4265
if (m != MATCH_YES)
return MATCH_ERROR;
! if (gfc_get_symbol (name, gfc_current_ns->parent, &sym))
return MATCH_ERROR;
if (sym->attr.proc != PROC_MODULE
--- 4268,4274
if (m != MATCH_YES)
return MATCH_ERROR;
! if (gfc_get_symbol (name, module_ns, &sym))
return MATCH_ERROR;
if (sym->attr.proc != PROC_MODULE
Index: gcc/testsuite/gfortran.dg/contained_module_proc_1.f90
===
*** gcc/testsuite/gfortran.dg/contained_module_proc_1.f90 (revision 0)
--- gcc/testsuite/gfortran.dg/contained_module_proc_1.f90 (revision 0)
***
*** 0
--- 1,40
+ ! { dg-do run }
+ ! Tests the check for PR31292, in which the module procedure
+ ! statement would put the symbol for assign_t in the wrong
+ ! namespace and this caused the interface checking to fail.
+ !
+ ! Contributed by Tobias Burnus <[EMAIL PROTECTED]>
+ !
+ module chk_gfortran
+implicit none
+type t
+ integer x
+end type t
+contains
+ function is_gfortran()
+ logical is_gfortran
+ interface assignment(=)
+ module procedure assign_t
+ end interface assignment(=)
+ type(t) y(3)
+
+ y%x = (/1,2,3/)
+ y = y((/2,3,1/))
+ is_gfortran = y(3)%x == 1
+ end function is_gfortran
+
+ elemental subroutine assign_t(lhs,rhs)
+ type(t), intent(in) :: rhs
+ type(t), intent(out) :: lhs
+
+ lhs%x = rhs%x
+ end subroutine assign_t
+ end module chk_gfortran
+
+ program fire
+use chk_gfortran
+implicit none
+if(.not. is_gfortran()) call abort()
+ end program fire
+ ! { dg-final { cleanup-modules "chk_gfortran" } }
+
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-03-27 10:21:29
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31292
[Bug fortran/31086] [4.2 only] ICE in fold_convert, at fold-const.c:2331
--- Comment #5 from pault at gcc dot gnu dot org 2007-03-27 10:26 --- Not a regression wrt to 4.1 so closing as fixed. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31086
[Bug bootstrap/31371] New: [4.3 regression] bootstrap error in libgcc, ICE in extract_insn, at recog.c:2119
seen with trunk 20070327, on powerpc-linux-gnu
gcc is configured with
--enable-languages=c,c++,fortran,objc,obj-c++,ada,treelang
--prefix=/usr/lib/gcc-snapshot --enable-shared --with-system-zlib
--disable-nls --enable-__cxa_atexit --enable-clocale=gnu --enable-mpfr
--disable-softfloat --enable-secureplt
--enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32
--disable-werror --with-long-double-128 --build=powerpc-linux-gnu
--host=powerpc-linux-gnu --target=powerpc-linux-gnu
/home/doko/gcc/snap/gcc-snapshot-20070327/build/./gcc/xgcc
-B/home/doko/gcc/snap/gcc-snapshot-20070327/build/./gcc/ -
B/usr/lib/gcc-snapshot/powerpc-linux-gnu/bin/
-B/usr/lib/gcc-snapshot/powerpc-linux-gnu/lib/ -isystem /usr/lib/gcc-sn
apshot/powerpc-linux-gnu/include -isystem
/usr/lib/gcc-snapshot/powerpc-linux-gnu/sys-include -g -fkeep-inline-functi
ons -m64 -fPIC -mstrict-align -O2 -O2 -g -O2 -DIN_GCC-W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-pro
totypes -Wold-style-definition -isystem ./include -fPIC -mno-minimal-toc -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GC
C_FLOAT_NOT_NEEDED -mlong-double-128 -I. -I. -I../../.././gcc
-I../../../../src/libgcc -I../../../../src/libgcc/. -I
../../../../src/libgcc/../gcc -I../../../../src/libgcc/../include
-I../../../../src/libgcc/../libdecnumber/dpd -I../.
./../../src/libgcc/../libdecnumber -I../../../libdecnumber -o _absvsi2.o -MT
_absvsi2.o -MD -MP -MF _absvsi2.dep -DL_
absvsi2 -c ../../../../src/libgcc/../gcc/libgcc2.c \
-fvisibility=hidden -DHIDE_EXPORTS
../../../src/libgcc/../gcc/libgcc2.c: In function '__addvsi3':
../../../src/libgcc/../gcc/libgcc2.c:93: error: unrecognizable insn:
(call_insn 34 32 35 7 ../../../src/libgcc/../gcc/libgcc2.c:90 (parallel [
(call (mem:SI (symbol_ref:SI ("abort") [flags 0x41] ) [0 S4 A8])
(const_int 0 [0x0]))
(use (const_int 0 [0x0]))
(clobber (scratch:SI))
]) -1 (nil)
(expr_list:REG_NORETURN (const_int 0 [0x0])
(expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil)))
(expr_list:REG_DEP_TRUE (use (reg:SI 30 30))
(nil)))
../../../src/libgcc/../gcc/libgcc2.c:93: internal compiler error: in
extract_insn, at recog.c:2119
--
Summary: [4.3 regression] bootstrap error in libgcc, ICE in
extract_insn, at recog.c:2119
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
GCC target triplet: powerpc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31371
[Bug bootstrap/31371] [4.3 regression] bootstrap error in libgcc, ICE in extract_insn, at recog.c:2119
--- Comment #1 from debian-gcc at lists dot debian dot org 2007-03-27 10:48 --- Created an attachment (id=13294) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13294&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31371
[Bug c++/31372] New: [4.3 Regression] Segfault in cp/parser.c: cp_parser_parameter_declaration
The following segfault happens with 4.3 SVN 20070318 and
20070326, works with 20070303.
(sid)4967:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++
democracyplayer-fasttypes.cc
democracyplayer-fasttypes.cc:2: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
zsh: exit 1 /usr/lib/gcc-snapshot/bin/g++ democracyplayer-fasttypes.cc
(sid)4968:[EMAIL PROTECTED]: ~] cat democracyplayer-fasttypes.cc
template < class U >
void foo (U (*), long ...)
{
}
Program received signal SIGSEGV, Segmentation fault.
cp_parser_parameter_declaration (parser=0x2b3a15801730, template_parm_p=0 '\0',
parenthesized_p=0x7fff959c8227 "") at
/home/tbm/scratch/gcc/gcc/cp/parser.c:12934
12934 if (DECL_P (type))
(gdb) where
#0 cp_parser_parameter_declaration (parser=0x2b3a15801730, template_parm_p=0
'\0',
parenthesized_p=0x7fff959c8227 "") at
/home/tbm/scratch/gcc/gcc/cp/parser.c:12934
#1 0x004c1c88 in cp_parser_parameter_declaration_clause
(parser=0x2b3a15801730)
at /home/tbm/scratch/gcc/gcc/cp/parser.c:12740
#2 0x004c232b in cp_parser_declarator (parser=0x2b3a15801730,
dcl_kind=CP_PARSER_DECLARATOR_NAMED, ctor_dtor_or_conv_p=0x7fff959c8360,
parenthesized_p=, member_p=0 '\0')
at /home/tbm/scratch/gcc/gcc/cp/parser.c:11967
#3 0x004c77ab in cp_parser_init_declarator (parser=0x2b3a15801730,
decl_specifiers=0x7fff959c83c0, checks=0x0, function_definition_allowed_p=1
'\001',
member_p=1 '\001', declares_class_or_enum=0,
function_definition_p=0x7fff959c841f "")
at /home/tbm/scratch/gcc/gcc/cp/parser.c:11476
#4 0x004c939c in cp_parser_single_declaration (parser=0x2b3a15801730,
checks=0x0,
member_p=1 '\001', friend_p=) at
/home/tbm/scratch/gcc/gcc/cp/parser.c:16375
#5 0x004c962e in cp_parser_template_declaration_after_export
(parser=0x2b3a15801730,
member_p=208 'â') at /home/tbm/scratch/gcc/gcc/cp/parser.c:16234
#6 0x004b30e9 in cp_parser_member_declaration (parser=0x2b3a15801730)
at /home/tbm/scratch/gcc/gcc/cp/parser.c:14206
#7 0x004b44d2 in cp_parser_type_specifier (parser=0x2b3a15801730,
flags=, decl_specs=0x7fff959c86a0, is_declaration=1
'\001',
declares_class_or_enum=0x7fff959c8640, is_cv_qualifier=)
at /home/tbm/scratch/gcc/gcc/cp/parser.c:14137
#8 0x004bdc3a in cp_parser_decl_specifier_seq (parser=0x2b3a15801730,
flags=CP_PARSER_FLAGS_OPTIONAL, decl_specs=0x7fff959c86a0,
declares_class_or_enum=0x7fff959c86f8)
at /home/tbm/scratch/gcc/gcc/cp/parser.c:7827
#9 0x004c91f3 in cp_parser_single_declaration (parser=0x2b3a15801730,
checks=0x0,
member_p=0 '\0', friend_p=0x7fff959c8757 "") at
/home/tbm/scratch/gcc/gcc/cp/parser.c:16319
#10 0x004c962e in cp_parser_template_declaration_after_export
(parser=0x2b3a15801730,
member_p=208 'â') at /home/tbm/scratch/gcc/gcc/cp/parser.c:16234
#11 0x004caf0a in cp_parser_declaration (parser=0x2b3a15801730)
at /home/tbm/scratch/gcc/gcc/cp/parser.c:7370
#12 0x004ca646 in cp_parser_declaration_seq_opt (parser=0x2b3a15801730)
at /home/tbm/scratch/gcc/gcc/cp/parser.c:7293
#13 0x004cae8d in cp_parser_declaration (parser=0x2b3a15801730)
at /home/tbm/scratch/gcc/gcc/cp/parser.c:11028
--
Summary: [4.3 Regression] Segfault in cp/parser.c:
cp_parser_parameter_declaration
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31372
[Bug c++/31372] [4.3 Regression] Segfault in cp/parser.c: cp_parser_parameter_declaration
--- Comment #1 from tbm at cyrius dot com 2007-03-27 10:54 --- Most likely caused by 2007-03-09 Douglas Gregor <[EMAIL PROTECTED]> PR c++/20599 ... -- tbm at cyrius dot com changed: What|Removed |Added CC||dgregor at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31372
[Bug bootstrap/31371] [4.3 regression] bootstrap error in libgcc, ICE in extract_insn, at recog.c:2119
--- Comment #2 from tbm at gcc dot gnu dot org 2007-03-27 10:56 --- Sorry for the bad communication. *** This bug has been marked as a duplicate of 31364 *** -- tbm at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31371
[Bug target/31364] [4.3 Regression] ICE in extract_insn, at recog.c:2119 during bootstrap
--- Comment #5 from tbm at gcc dot gnu dot org 2007-03-27 10:56 --- *** Bug 31371 has been marked as a duplicate of this bug. *** -- tbm at gcc dot gnu dot org changed: What|Removed |Added CC||debian-gcc at lists dot ||debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31364
[Bug rtl-optimization/31373] New: [4.2 Regression] -fsection-anchors causes multiple definitions
The testcase below causes multiple definitions if current_namespace with
compiling with -O on ppc and ppc64:
.LFE2:
.size _Z24add_defined_foreign_typev,.-_Z24add_defined_foreign_typev
.section".bss"
.align 2
.set.LANCHOR0,. + 0
.type current_namespace, @object
.size current_namespace, 4
current_namespace:
.zero 4
.type current_namespace, @object
.size current_namespace, 4
current_namespace:
.zero 4
.section.eh_frame,"a",@progbits
-fno-section-anchors fixes it.
void *f1();
void f2(void *);
static void *current_namespace = f1();
void *namespaced_name(void *ns = current_namespace);
void add_defined_foreign_type() {
void *k;
k = namespaced_name();
f2(k); // make sure k isn't optimized out
}
--
Summary: [4.2 Regression] -fsection-anchors causes multiple
definitions
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: blocker
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: powerpc*-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31373
exp(float) much slower than exp(double)
Hi, using some simple benchmark I just found out that exp(float) takes about 8 times more time than exp(double). gprofing my benchmark gives: 44.26 5.34 5.34 fesetenv 19.49 7.69 2.35 fesetround 14.97 9.49 1.81 feholdexcept 13.40 11.11 1.62 __ieee754_expf ...So most time is wasted(?) in functions never called when the benchmark is compiled to use doubles. Sorry if I sent this to the wrong address, best regards W. A. Svrcek-Seiler P.S.: gcc -v says Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.1 20070105 (Red Hat 4.1.1-51) (stock fedora core 6, that is)
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #17 from thutt at vmware dot com 2007-03-27 13:49 --- In response to comment #16: I wouldn't call an inliner which inlines functions specifically marked as "do not put this in '.text'" as 'smart'. I'd use a more pejorative adjective, such as 'broken' or 'dumb'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug tree-optimization/31375] New: missed loop-if transformation / branch reduction.
long condition( void );
long f1( void );
long f2( void );
void foo( void )
{
for ( ;; )
if ( condition() )
f1();
else
f2();
}
foo() could be transformed to bar():
void bar( void )
{
long (* f[ 2 ])() = { &f2, &f1 };
for ( ;; )
f[ condition() ]();
}
--
Summary: missed loop-if transformation / branch reduction.
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31375
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-03-27 14:22 --- Well, you can continue to waste your time arguing here instead of fixing your code with a few additions of noinline. 'The `section' attribute specifies that a function lives in a particular section.' this just says that the function (the out-of-line copy) lives in a particular section. It doesn't mention inlined copies of the function _body_. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug tree-optimization/31375] missed loop-if transformation / branch reduction.
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-27 14:24 --- Uh, an indirect call is much more expensive in general unless you can prove that the branch if (condition()) is completely random and so usually mispredicted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31375
[Bug c/31362] gcc should not inline functions with 'section' attribute
--- Comment #19 from thutt at vmware dot com 2007-03-27 14:44 --- I guess I need a bigger typeface because I don't see where it says '(the out-of-line copy)'. Or, perhaps, you've simply added that '(the out-of-line copy)' annotation yourself because that's what the code currently does, and because it suits your agenda. I guess you also felt free to interpret that it's ok to inline such functions, even though it doesn't say any such thing, and even though it goes against exactly what the 'section' attribute intends to do. But, as you stated, it's a waste of my time, and you folks obviously aren't going to treat this as a legitmate defect, so there's no point in continuing this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
[Bug c++/31141] [4.3 regression] ICE with ellipsis in template parameter list
--- Comment #1 from doug dot gregor at gmail dot com 2007-03-27 15:10 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00799.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31141
[Bug c++/31372] [4.3 Regression] Segfault in cp/parser.c: cp_parser_parameter_declaration
--- Comment #2 from doug dot gregor at gmail dot com 2007-03-27 15:10 --- Does the following patch solve the problem? http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00799.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31372
[Bug c++/31140] [4.3 regression] ICE with ellipsis in template parameter list
--- Comment #1 from doug dot gregor at gmail dot com 2007-03-27 15:12 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00799.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31140
[Bug c++/31138] [4.3 regression] ICE with ellipsis
--- Comment #4 from doug dot gregor at gmail dot com 2007-03-27 15:12 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00799.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31138
[Bug c++/31372] [4.3 Regression] Segfault in cp/parser.c: cp_parser_parameter_declaration
--- Comment #3 from tbm at gcc dot gnu dot org 2007-03-27 15:18 --- *** This bug has been marked as a duplicate of 31138 *** -- tbm at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31372
[Bug c++/31138] [4.3 regression] ICE with ellipsis
--- Comment #5 from tbm at gcc dot gnu dot org 2007-03-27 15:18 --- *** Bug 31372 has been marked as a duplicate of this bug. *** -- tbm at gcc dot gnu dot org changed: What|Removed |Added CC||tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31138
[Bug c++/31372] [4.3 Regression] Segfault in cp/parser.c: cp_parser_parameter_declaration
--- Comment #4 from tbm at cyrius dot com 2007-03-27 15:44 --- (In reply to comment #2) > Does the following patch solve the problem? > > http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00799.html Yes, with the typo (TREDE) corrected this work. Sorry, I thought I had seen this patch before but couldn't find it before I opened this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31372
[Bug preprocessor/14331] please add option to suppress warning message "no newline at end of file"
--- Comment #11 from dave dot korn at artimi dot com 2007-03-27 16:26 --- Tom: The status is "Ooops, completely forgot about that one". (Well, to be fair, it's "Ooops, never even knew about that one as I wasn't on the Cc: list for this bug until I stumbled across it today purely by chance"; Dan Kegel added my patch to this PR, Andrew Pinski thought I was on the Cc list at comment #7 but I wasn't so this is the first I know of it!) The issue just came up on the gcc list today, though, so I think I should pick it back up. If I forget again, please feel free to drop me private email to remind me. Manuel: Yes, the patch is against 3.3 series, I didn't actually formally submit it but just posted it to the list when someone was in need of a patch. See http://gcc.gnu.org/ml/gcc/2004-07/msg00798.html Before resubmitting I would /of course/ a) up-port to current mainline b) use the most appropriate of the current options-handling mechanisms and c) add testcases and docs. Can you advise me what you think the best way to add the option is? I particularly think I ought to avoid "manually copying a global in c_common_post_options" (as I wrote at url above). -- dave dot korn at artimi dot com changed: What|Removed |Added CC||dave dot korn at artimi dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14331
[Bug c/31324] Building libgcc2 on x86_64 for m68k-elf: internal compiler error: in do_SUBST, at combine.c:462
--- Comment #5 from schwab at suse dot de 2007-03-27 16:36 --- *** This bug has been marked as a duplicate of 28911 *** -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.2.0 Resolution||DUPLICATE Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31324
[Bug target/28911] Cross compiler build for m68k--elf fails on x86_64-linux-gnu
--- Comment #10 from schwab at suse dot de 2007-03-27 16:36 --- *** Bug 31324 has been marked as a duplicate of this bug. *** -- schwab at suse dot de changed: What|Removed |Added CC||zdenekjs at sarpeidon dot ||net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28911
[Bug c++/31373] [4.2 Regression] -fsection-anchors causes multiple definitions
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-27 16:40 --- I thought I fixed this already. See PR 31165. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|rtl-optimization|c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31373
[Bug target/31364] [4.3 Regression] ICE in extract_insn, at recog.c:2119 during bootstrap
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-03-27 16:42 --- It must be related to "--enable-secureplt" which I don't enable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31364
[Bug c++/31165] [4.2/4.3 Regression] Error: symbol `an_empty_string' is already defined
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-03-27 16:51 --- *** Bug 31373 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31165
[Bug c++/31373] [4.2 Regression] -fsection-anchors causes multiple definitions
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-27 16:51 --- Next time show the revision or the date and do what the bugs.html says to do and test a newer compiler :). *** This bug has been marked as a duplicate of 31165 *** -- 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=31373
[Bug fortran/31292] ICE with module procedure interface in a procedure body
--- Comment #2 from patchapp at dberlin dot org 2007-03-27 17:05 --- Subject: Bug number PR31292 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01763.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31292
[Bug target/31364] [4.3 Regression] ICE in extract_insn, at recog.c:2119 during bootstrap
--- Comment #7 from tbm at cyrius dot com 2007-03-27 18:01 --- (In reply to comment #6) > It must be related to "--enable-secureplt" which I don't enable. You are, of course, correct. You can reproduce it with: --enable-languages=c --enable-secureplt powerpc-linux-gnu Any idea who might be responsible and how to go about to get this fixed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31364
[Bug libstdc++/31368] basic_string and unsigned short leads to memory fault
--- Comment #6 from pcarlini at suse dot de 2007-03-27 18:07 --- To restate my point: if, with a recent compiler, I change the testcase to use , which has completely different memory management, instead of , even for plain char I get an immediate Segmentation Fault without any debugging information available. Thus, I strongly suspect the testcase is somehow broken and must be fixed first: I can do that eventually, but feedback from the original submitter is strongly encouraged, of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31368
[Bug objc/31281] ICE on ObjC try-catch blocks with next runtime
--- Comment #3 from stuart at apple dot com 2007-03-27 18:18 --- Patch offered here: http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01328.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31281
[Bug libstdc++/31368] basic_string and unsigned short leads to memory fault
--- Comment #7 from gregoryk at edifecs dot com 2007-03-27 18:20 --- Unfortunately I do not have possibility to run my test case using latest GCC compiler. Im limited in hardware and software choice. Besides Im not sure what do you mean to fix testcase. If you could fix it then it will be accepted in any way by me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31368
[Bug libstdc++/31368] basic_string and unsigned short leads to memory fault
--- Comment #8 from pcarlini at suse dot de 2007-03-27 18:24 --- (In reply to comment #7) > Unfortunately I do not have possibility to run my test case using latest GCC > compiler. Im limited in hardware and software choice. Besides Im not sure > what do you mean to fix testcase. As I said, the testcase Segfaults badly on any recent machine, for but also for and also for plain char. This is unfortunate, this is not the behavior you expected when you submitted the PR, and if we cannot reproduce the issue that you are maintaining to see we cannot understand it and we cannot take any further action. Can you please double check you are building the so, dlopening, etc, in your testcase in the correct, portable way? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31368
[Bug libstdc++/31368] basic_string and unsigned short leads to memory fault
--- Comment #9 from pcarlini at suse dot de 2007-03-27 18:36 --- I get an immediate Segmentation fault even if I change read_string to do nothing.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31368
[Bug libstdc++/31368] basic_string and unsigned short leads to memory fault
--- Comment #10 from gregoryk at edifecs dot com 2007-03-27 18:39 ---
Got it, thanks. In may original test I was relaying on LD_LIBRARY_PATH to have
current folder in the values. And there was no checking of dlopen result for
simplicity. Here is updated code. It will search for libloader.so in current
folder.
#include
#include
#include "loader.h"
typedef void *pfLoader(std::ustring&);
int main(int argc, char* argv[])
{
void * libHandle = dlopen("./libloader.so", RTLD_NOW|RTLD_GLOBAL);
if (0 == libHandle)
{
printf("Can not load \"./libloader.so\".\n");
return 1;
}
pfLoader* pF = (pfLoader*)dlsym(libHandle, "read_string");
if (0 == pF)
{
printf("Can not find function \"read_string\" in
libloader.so\n");
return 2;
}
std::ustring s;
// s.reserve(1); // uncomment this line to prevent abort
pF(s);
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31368
[Bug libstdc++/31368] basic_string and unsigned short leads to memory fault
--- Comment #11 from gregoryk at edifecs dot com 2007-03-27 18:40 --- Forgot to mention, that was main.cpp code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31368
[Bug c/31377] New: wrap_help error
in the file "opts.c", in the function "wrap_help", the var 'room' is calculated as the space remaining between the the left item field width and the rightmost column (which defaults to 80 chars). it is then compared to the columns value: room = columns - 3 - MAX (col_width, item_width); if (room > columns) room = 0; len = remaining; I assume this is supposed to determine if the left field is taking up more than the entire width of the line and if so, sets it to 0 as there is no room left. to do this, the correct code should be room = columns - 3 - MAX (col_width, item_width); if (room < 0) room = 0; len = remaining; admitedly, since all the help lines that print out don't have a left field that comes close to taking up the entire line, this case never occurs, so this is a trival case. -- Summary: wrap_help error Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: george at houseofellery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31377
[Bug tree-optimization/31375] missed loop-if transformation / branch reduction.
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-27 19:01 ---
This is not even a size win for either x86-linux or powerpc{,64}-linux-gnu so
closing as invalid.
--
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=31375
[Bug libstdc++/31368] basic_string and unsigned short leads to memory fault
--- Comment #12 from pcarlini at suse dot de 2007-03-27 19:22 --- Ok, now I see. The kind of issue is unfortunately known, akin to 24196 for example, and ultimately due to the special, optimized way we are dealing with empty strings, not allocating dynamic memory at all. I don't think we can really solve the problem without breaking the binary compatibility of the entire library, therefore we suggest various options: 1- Make sure to never deal with empty strings (which means a string not holding a memory buffer, that's why reserve(1) works, for example) 2- Rebuild the library passing --enable-fully-dynamic-string, the option has been added exactly to help users in this case. 3- Switch to a different implementation of the string class: in recent releases we are offering one under (will become standard when we decide to break binary compatibility) -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|WAITING |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-27 19:22:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31368
[Bug libstdc++/31368] basic_string and unsigned short leads to memory fault
--- Comment #13 from pcarlini at suse dot de 2007-03-27 19:25 --- By the way, as a matter of portability, isn't a good idea to use the string class with anything != char and wchar_t: things usually work in rather recent releases of GCC only because we are delivering a "generic" implementation of char_traits, which cannot be assumed, in general (and that's why probably your specific issue with empty strings has not been reported earlier). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31368
[Bug libstdc++/31368] basic_string and unsigned short leads to memory fault
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31368
[Bug c++/31378] New: "too few template-parameter-lists" when initializing static template member
When compiling the following program the g++ 4.1.0 gives the error message:
"testtemplstatic.cpp:22: error: too few template-parameter-lists". Which I
interprete as a complaint, that a "template<>" is missing.
If I uncomment the "template<>" in line 21 g++ prints the error message:
"testtemplstatic.cpp:22: error: template header not allowed in member
definition of explicitly specialized class", which I interprete as having a
"template<>" too much.
One of the both versions (presumably the first) should be correct.
My configuration:
> g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.0/configure
--prefix=/flc/flc03/data/samson/soft/gcc/4.1.0 --enable-languages=c,c++
Thread model: posix
gcc version 4.1.0
Regretfully I cannot check the bug with an 4.1.2 version of g++, as the
compilation of gcc 4.1.2 fails with an linker error on a Scientific Linux
(RHEL3) machine.
Cheers, T.
#include
using namespace std;
template< class T >
struct foo
{
struct bar;
};
template<>
struct foo::bar
{
const static char* blubb;
};
template struct foo;
//template<>
const char* foo::bar::blubb = "huhu";
int main()
{
cout << foo::bar::blubb
[Bug target/31364] [4.3 Regression] secureplt breaks bootstrap
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-27 19:45 --- Confirmed, looking into it. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||build, ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2007-03-27 19:45:11 date|| Summary|[4.3 Regression] ICE in |[4.3 Regression] secureplt |extract_insn, at|breaks bootstrap |recog.c:2119 during | |bootstrap | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31364
[Bug libstdc++/31368] basic_string and unsigned short leads to memory fault
--- Comment #14 from gregoryk at edifecs dot com 2007-03-27 19:51 --- Thank you for info. The sample is working now with _GLIBCXX_FULLY_DYNAMIC_STRING turned on. What is the next procedure with bug status? For me bug can be marked as FIXED. Regarding portability. We use unsigned short strings on more then 6 platforms and would like to continue this way. We use custom implementation of char_traits where it is not available. And looking on migration on Xerces STL as a common solution for all platforms (yes, it is not easy but worth to try). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31368
[Bug libstdc++/31368] basic_string and unsigned short leads to memory fault
--- Comment #15 from pcarlini at suse dot de 2007-03-27 19:53 --- Ok, I will mark it as suspended, because when we break the binary compatibility things will always work fine. -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31368
[Bug target/31364] [4.3 Regression] secureplt breaks bootstrap
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-03-27 19:57 --- I think I found the missing conversion of using LR register explictly. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-03-27 19:45:11 |2007-03-27 19:57:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31364
[Bug c++/31378] "too few template-parameter-lists" when initializing static template member
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-27 20:03 --- This has been fixed on the trunk for sure, I don't when it was fixed either. It fails in 4.1.1 also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31378
[Bug fortran/31366] When the last record written to a direct access file is shorter than the record length of the file, gfortran truncates the record
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-03-27 20:04 --- This is the same behavor that g77 had. Also, reading back what we have written works for both gfortran and g77: $ cat tst.f PROGRAM MAIN character*1 c OPEN (76, FILE="test.txt",ACCESS="DIRECT",STATUS="NEW",RECL=10) WRITE(76, REC=1) "1" read (76, REC=1) c print *,c END $ g77 tst.f $ ./a.out 1 $ rm -f test.txt $ gfortran tst.f $ ./a.out 1 Offhand, I don't think this is wrong. The Fortran standard talks about records, not about bytes in a file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31366
[Bug target/31364] [4.3 Regression] secureplt breaks bootstrap
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-03-27 20:07 --- The patch which I am testing: Index: config/rs6000/rs6000.md === --- config/rs6000/rs6000.md (revision 123248) +++ config/rs6000/rs6000.md (working copy) @@ -10715,7 +10715,9 @@ gen_rtx_MEM (SImode, operands[0]), operands[1]), gen_rtx_USE (VOIDmode, operands[2]), - gen_rtx_CLOBBER (VOIDmode, gen_rtx_SCRATCH (SImode))); + gen_rtx_CLOBBER (VOIDmode, + gen_rtx_REG (Pmode, +LINK_REGISTER_REGNUM))); call = emit_call_insn (gen_rtx_PARALLEL (VOIDmode, tmp)); use_reg (&CALL_INSN_FUNCTION_USAGE (call), pic_offset_table_rtx); DONE; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31364
[Bug libstdc++/31370] resizing bugs in std::vector
--- Comment #6 from gcc at severeweblint dot org 2007-03-27 20:27 ---
4.2 doesn't fix any of the problems, but it does make the max_size
issue a bit more confusing.
There is a subtle relationship between vector size and
pointers. Pointers can address only SIZE_MAX memory. But iterators
takes ssize_t as arguments to addition and subtraction operators, so
vector size should be limited to SSIZE_MAX. For sizeof(_Tp) of at
least 2 bytes, there is no problem. The pointer limitation implies a
size limit of SIZE_MAX / sizeof(_Tp) which is less than SSIZE_MAX. For
sizeof(_Tp) of one byte, things deserve to be broken, but manage
not to be. The fact that for two size_t x1 and x2, it is always true
that size_t(x1+x2) == size_t(x1+ssize_t(y)) manages to rescue the
situation.
But for vector, things break down completely and the max_size
becomes limited by SSIZE_MAX, not the pointer limitation. Worse,
because of the round up to the nearest word, the max_size actually has
to be SSIZE_MAX rounded DOWN to the nearest word.
So allowing for the allocator to have its own size limit, the
implementation of max_size has to become
size_type
max_size() const
{
const size_type __isize = SSIZE_MAX - int(_S_word_bit) + 1;
const size_type __asize = _M_get_Bit_allocator().max_size();
return (__asize < __isize / size_type(_S_word_bit) ?
__asize * size_type(_S_word_bit) : __isize);
}
Note that it probably isn't correct to assume that difference_type is
a ssize_t, and therefore has maximum SSIZE_MAX, but I don't see what
the correct way to ask what the maximum value representable by
difference_type is.
I'm fine with filling out copyright assignment paperwork, but I didn't see the
form at the link you gave me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31370
[Bug target/31364] [4.3 Regression] secureplt breaks bootstrap
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-03-27 20:33 --- I missed another gen_rtx_SCARTCH also: Index: gcc/gcc/config/rs6000/rs6000.md === --- gcc/gcc/config/rs6000/rs6000.md (revision 123248) +++ gcc/gcc/config/rs6000/rs6000.md (working copy) @@ -10715,7 +10715,9 @@ gen_rtx_MEM (SImode, operands[0]), operands[1]), gen_rtx_USE (VOIDmode, operands[2]), - gen_rtx_CLOBBER (VOIDmode, gen_rtx_SCRATCH (SImode))); + gen_rtx_CLOBBER (VOIDmode, + gen_rtx_REG (Pmode, +LINK_REGISTER_REGNUM))); call = emit_call_insn (gen_rtx_PARALLEL (VOIDmode, tmp)); use_reg (&CALL_INSN_FUNCTION_USAGE (call), pic_offset_table_rtx); DONE; @@ -10788,7 +10790,9 @@ operands[1]), operands[2])), gen_rtx_USE (VOIDmode, operands[3]), - gen_rtx_CLOBBER (VOIDmode, gen_rtx_SCRATCH (SImode))); + gen_rtx_CLOBBER (VOIDmode, + gen_rtx_REG (Pmode, + LINK_REGISTER_REGNUM; call = emit_call_insn (gen_rtx_PARALLEL (VOIDmode, tmp)); use_reg (&CALL_INSN_FUNCTION_USAGE (call), pic_offset_table_rtx); DONE; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31364
[Bug target/31364] [4.3 Regression] secureplt breaks bootstrap
--- Comment #12 from tbm at cyrius dot com 2007-03-27 20:44 --- (In reply to comment #11) > + > LINK_REGISTER_REGNUM; This should be: LINK_REGISTER_REGNUM))); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31364
[Bug c++/31378] "too few template-parameter-lists" when initializing static template member
--- Comment #2 from trumsko at yahoo dot com 2007-03-27 20:56 --- Finally I managed to compile the 4.1.2 version of gcc and the error does not occur any more. -- trumsko at yahoo dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31378
[Bug libstdc++/31370] resizing bugs in std::vector
--- Comment #7 from pcarlini at suse dot de 2007-03-27 21:03 --- Two quick replies: > 4.2 doesn't fix any of the problems, but it does make the max_size > issue a bit more confusing. Thanks, this is encouraging ;) In any case, nobody said 4.2 fixed any of those problems. However, for sure, any proposed patch / fix targets first mainline, not the release branches. > Note that it probably isn't correct to assume that difference_type is > a ssize_t, and therefore has maximum SSIZE_MAX, but I don't see what > the correct way to ask what the maximum value representable by > difference_type is. Why not numeric_limits::max() ? > I'm fine with filling out copyright assignment paperwork, but I didn't see the > form at the link you gave me. Again, nobody said the form was there. I pointed you at that general information page because I was under the - probably not too far from the truth - impression that you was not familiar with our general directions for contributors. If you need the forms, please send a message to [EMAIL PROTECTED] In any case, that kind of paperwork is not needed for the present work, but, if possible, please let's figure out a way to deal with the issues in a "C++" (C++03, actually) way, which means using numeric_limits, not assuming specific types for difference_type, size_type and so on, not using types likes ssize_t which do not exist in the current C++ standard (*). Finally, I repeat myself, any patch shall target mainline first. I look forward to see your improved proposal. (*) ssize_t is mentioned only once, in note 266. If we really need a type equivalent for all practical matters to such Posix type, we have to find a way to construct one on the fly, for example by implementing an __add_signed (similar to the currently available __add_unsigned, in ext/type_traits.h) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31370
[Bug ada/24994] raised STORAGE_ERROR : stack overflow or erroneous memory access
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2007-03-27 22:37 --- Dave, does the problem still exist on the 4.2 branch for the PA? I'm now seeing it (same backtrace) on a patched 4.1 branch for x86-64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24994
[Bug preprocessor/14331] please add option to suppress warning message "no newline at end of file"
--- Comment #12 from manu at gcc dot gnu dot org 2007-03-28 00:21 --- (In reply to comment #11) > Manuel: Yes, the patch is against 3.3 series, I didn't actually formally > submit it but just posted it to the list when someone was in need of a patch. > See > > http://gcc.gnu.org/ml/gcc/2004-07/msg00798.html > > Before resubmitting I would /of course/ a) up-port to current mainline b) > use > the most appropriate of the current options-handling mechanisms and c) add > testcases and docs. Can you advise me what you think the best way to add the > option is? I particularly think I ought to avoid "manually copying a global > in c_common_post_options" (as I wrote at url above). > I was not criticizing your patch. Tom asked and I gave my opinion: that the patch would need to be updated by someone (not necessarily you) before being accepted. To see the proper way to add the option look for endif_labels in c.opt and c-opts.c. Notice that you don't need to define a global option anymore in gcc/flags.h (although it seems that you still need it in libcpp/include/cpplib.h). To keep current behaviour, you need to enable the option by default. If it were a front-end option you would need to enable it in c.opt using Init(1) (see other options in the same file). However, I don't think that setting affects automatically CPP options, so probably you need to set the option in libccp/init.c as you do in your original patch. Of course, you also need to conditionalize the warning on the option, but your patch already does this. I hope this helps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14331
[Bug ada/24994] raised STORAGE_ERROR : stack overflow or erroneous memory access
--- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca 2007-03-28 00:49 --- Subject: Re: raised STORAGE_ERROR : stack overflow or erroneous memory access > Dave, does the problem still exist on the 4.2 branch for the PA? I'm > now seeing it (same backtrace) on a patched 4.1 branch for x86-64. No. Ada builds successfully on all PA targets that support it on both 4.1 and 4.2. However, my 4.1 builds aren't very recent. All results are posted. Don't remember what fixed comment #13. Possibly, a change just made the issue latent. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24994
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- Comment #31 from dave at hiauly1 dot hia dot nrc dot ca 2007-03-28
00:58 ---
Subject: Re: Bootstrap comparison error at revision 122821
> /* If we have a RSHIFT_EXPR with a possibly negative shift
> count or an anti-range shift count drop to VR_VARYING.
> We currently cannot handle the overflow cases correctly. */
> if (code == RSHIFT_EXPR
> && (vr1.type == VR_ANTI_RANGE
> || !vrp_expr_computes_nonnegative (op1, &sop)))
> {
> set_value_range_to_varying (vr);
> return;
> }
>
> we make sure neither vr0 nor vr1 are anti-ranges and vr1 is >= 0.
Don't see the check to make sure vr0 isn't an anti-range. It
was eliminated by the hunk 3 change.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug bootstrap/31379] New: make[3]: *** [s-gtype] Segmentation fault (core dumped)
In stage1: ... /bin/sh ../../gcc/gcc/../move-if-change tmp-gi.list gtyp-input.list echo timestamp > s-gtyp-input build/gengtype ../../gcc/gcc gtyp-input.list make[3]: *** [s-gtype] Segmentation fault (core dumped) (gdb) r ../../gcc/gcc gtyp-input.list Starting program: /test/gnu/gcc/objdir/gcc/build/gengtype ../../gcc/gcc gtyp-input.list warning: The shared libraries were not privately mapped; setting a breakpoint in a shared library will not work until you rerun the program. Breakpoint 3 at 0xc002a800 Breakpoint 3 at 0x7af867fc Program received signal SIGSEGV, Segmentation fault. 0x7aff5844 in __ldfcvt_r () from /usr/lib/libc.2 (gdb) bt #0 0x7aff5844 in __ldfcvt_r () from /usr/lib/libc.2 #1 0x7aff5580 in _doprnt () from /usr/lib/libc.2 #2 0x7b007fbc in vsnprintf () from /usr/lib/libc.2 #3 0x6be8 in oprintf (o=0x4000b6b8, format=0x14b48 "/* Type information for %s.\n") at ../../gcc/gcc/gengtype.c:1488 #4 0x6af4 in create_file (name=0x14cdc "GCC", oname=0x14ce0 "gtype-desc.h") at ../../gcc/gcc/gengtype.c:1472 #5 0x6d80 in open_base_files () at ../../gcc/gcc/gengtype.c:1528 #6 0xd250 in main (argc=3, argv=0x7eff04cc) at ../../gcc/gcc/gengtype.c:3560 -- Summary: make[3]: *** [s-gtype] Segmentation fault (core dumped) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31379
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #35 from jvdelisle at gcc dot gnu dot org 2007-03-28 01:19 --- Subject: Bug 31052 Author: jvdelisle Date: Wed Mar 28 01:19:39 2007 New Revision: 123284 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123284 Log: 2007-03-27 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/31052 * io/transfer.c (next_record_r): Do not call test_endfile if in namelist mode. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug target/31109] gcc 3.3 not functioning under Interix 3.5
--- Comment #1 from lordface at gmail dot com 2007-03-28 01:34 --- I also have this problem. I have a pentium D in this computer - maybe its a conflict that exists when you have multi-core processors? (In reply to comment #0) > gcc 3.3 is working fine in Interix (Services for Unix under Windows) on other > Windows XP machines that I use (both laptop and desktop) > A new installation of SFU35SEL_EN.exe (SFU/Interix) on a new IBM ThinkPad > laptop with Centrino Duo procesor does not seem to allow compilation of any > program (I for instance tried the well-known dedos program). The system > description is: > Interix 3.5 SP-8.0.1969.1 x86 Intel_x86_Family6_Model15_Stepping6 > while the reported error message (in response to: gcc dedos.c) is: > gcc; Internal error: Segmentation fault (program cc1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31109
[Bug fortran/31199] write with "t1" + nonadvancing transfer format gives wrong output
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2007-03-28 01:48 --- Not a regression, closing. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31199
[Bug fortran/31366] When the last record written to a direct access file is shorter than the record length of the file, gfortran truncates the record
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-03-28 01:53 --- Closing as not a bug. If anyone sees something in the standard otherwise, please let me know. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31366
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #36 from jvdelisle at gcc dot gnu dot org 2007-03-28 01:59 --- Closing, will not backport to 4.2 unless someone feels strongly about it. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug target/31380] New: Typo in gcc/config/i386/sse.md
gcc/config/i386/sse.md has
(define_expand "uminv16qi3"
[(set (match_operand:V16QI 0 "register_operand" "")
(umin:V16QI (match_operand:V16QI 1 "nonimmediate_operand" "")
(match_operand:V16QI 2 "nonimmediate_operand" "")))]
"TARGET_SSE2"
"ix86_fixup_binary_operands_no_copy (UMAX, V16QImode, operands);")
Shouldn't it be UMIN?
--
Summary: Typo in gcc/config/i386/sse.md
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31380
[Bug libgcj/22579] URLClassLoader re-merge plan
--- Comment #4 from tromey at gcc dot gnu dot org 2007-03-28 02:08 --- Gary fixed this a while back. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22579
[Bug libgcj/26910] re-merging java.util.zip
--- Comment #4 from tromey at gcc dot gnu dot org 2007-03-28 02:19 --- All the problems were ironed out and now this is fixed. As of 4.2 we only differ in Deflater and Inflater, which is tolerable. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26910
[Bug libgcj/30903] regeneration of headers is broken/difficult
--- Comment #2 from tromey at gcc dot gnu dot org 2007-03-28 02:23 --- Mine. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-28 02:23:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30903
[Bug bootstrap/31381] New: make[3]: *** [s-gtype] Segmentation fault (core dumped)
In stage1: ... /bin/sh ../../gcc/gcc/../move-if-change tmp-gi.list gtyp-input.list echo timestamp > s-gtyp-input build/gengtype ../../gcc/gcc gtyp-input.list make[3]: *** [s-gtype] Segmentation fault (core dumped) (gdb) r ../../gcc/gcc gtyp-input.list Starting program: /test/gnu/gcc/objdir/gcc/build/gengtype ../../gcc/gcc gtyp-input.list warning: The shared libraries were not privately mapped; setting a breakpoint in a shared library will not work until you rerun the program. Breakpoint 3 at 0xc002a800 Breakpoint 3 at 0x7af867fc Program received signal SIGSEGV, Segmentation fault. 0x7aff5844 in __ldfcvt_r () from /usr/lib/libc.2 (gdb) bt #0 0x7aff5844 in __ldfcvt_r () from /usr/lib/libc.2 #1 0x7aff5580 in _doprnt () from /usr/lib/libc.2 #2 0x7b007fbc in vsnprintf () from /usr/lib/libc.2 #3 0x6be8 in oprintf (o=0x4000b6b8, format=0x14b48 "/* Type information for %s.\n") at ../../gcc/gcc/gengtype.c:1488 #4 0x6af4 in create_file (name=0x14cdc "GCC", oname=0x14ce0 "gtype-desc.h") at ../../gcc/gcc/gengtype.c:1472 #5 0x6d80 in open_base_files () at ../../gcc/gcc/gengtype.c:1528 #6 0xd250 in main (argc=3, argv=0x7eff04cc) at ../../gcc/gcc/gengtype.c:3560 -- Summary: make[3]: *** [s-gtype] Segmentation fault (core dumped) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31381
[Bug libfortran/31297] Use of uninitialized variables in libgfortran's I/O
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-03-28 02:28 --- I think this can be closed. No need to backport. RE-open if anyone disagrees. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31297
[Bug bootstrap/31381] make[3]: *** [s-gtype] Segmentation fault (core dumped)
--- Comment #1 from danglin at gcc dot gnu dot org 2007-03-28 02:30 --- Sorry, I inadvertantly duplicated PR 31379. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31381
[Bug bootstrap/31379] make[3]: *** [s-gtype] Segmentation fault (core dumped)
--- Comment #1 from danglin at gcc dot gnu dot org 2007-03-28 02:35 --- (gdb) p ap $10 = (va_list) 0x7eff0718 (gdb) p (char *)0x7eff0718 $11 = 0x7eff0718 "" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31379
[Bug bootstrap/31379] make[3]: *** [s-gtype] Segmentation fault (core dumped)
--- Comment #2 from danglin at gcc dot gnu dot org 2007-03-28 02:39 ---
This is more likely the problem:
(gdb) p *o
$7 = {next = 0x0, name = 0x14ce0 "gtype-desc.h", buflength = 0, bufused = 0,
buf = 0x0}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31379
[Bug fortran/31298] Uninitialized variable in f951 (in read_module)
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-03-28 02:39 --- I will try this one. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-28 02:39:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31298
[Bug target/31380] [4.1/4.2/4.3]: Typo in gcc/config/i386/sse.md
--- Comment #1 from hjl at lucon dot org 2007-03-28 03:56 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01813.html -- hjl at lucon dot org changed: What|Removed |Added Keywords||patch Summary|Typo in |[4.1/4.2/4.3]: Typo in |gcc/config/i386/sse.md |gcc/config/i386/sse.md http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31380
[Bug target/31364] [4.3 Regression] secureplt breaks bootstrap
--- Comment #13 from tbm at cyrius dot com 2007-03-28 04:04 --- Bootstrap is successful with your patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31364
[Bug fortran/31298] Uninitialized variable in f951 (in read_module)
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-03-28 04:21 --- Valgrind gives no error related to uninitialized when compiling with gfortran. I am not sure this is a problem of real concern. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31298
[Bug c++/31382] New: Internal compiler Error (Is this a bug?)
Hi: I got this error error message when I tried to compile icu (http://www.icu-project.org) g++ -DU_I18N_IMPLEMENTATION -I. -I../common -O2 -fno-common -c -dynamic -o dtfmtsym.o dtfmtsym.cpp dtfmtsym.cpp: In member function `void icu_3_6::DateFormatSymbols::initializeData(const icu_3_6::Locale&, const char*, UErrorCode&, UBool)': dtfmtsym.cpp:1084: internal compiler error: in cp_tree_equal, at cp/tree.c:1679 gnumake[1]: *** [dtfmtsym.o] Error 1 gnumake: *** [all-recursive] Error 2 Here are some build environment information below: Platform : MacOSX 10.4.8 GCC Version : 4.0.0 G++ Version : 4.0.0 GNUMake Version:3.80 Sincerely, ludwig lim -- Summary: Internal compiler Error (Is this a bug?) Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludz_lim at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31382
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- Comment #32 from rguenth at gcc dot gnu dot org 2007-03-28 08:52
---
There is
/* Refuse to operate on VARYING ranges, ranges of different kinds
and symbolic ranges. As an exception, we allow BIT_AND_EXPR
because we may be able to derive a useful range even if one of
the operands is VR_VARYING or symbolic range. TODO, we may be
able to derive anti-ranges in some cases. */
if (code != BIT_AND_EXPR
&& code != TRUTH_AND_EXPR
&& code != TRUTH_OR_EXPR
&& (vr0.type == VR_VARYING
|| vr1.type == VR_VARYING
|| vr0.type != vr1.type
|| symbolic_range_p (&vr0)
|| symbolic_range_p (&vr1)))
{
set_value_range_to_varying (vr);
return;
}
which sets the value range to varying if vr0.type != vr1.type, so if
vr1.type is not an anti-range, then vr0.type isn't either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
