[Bug target/31388] ICE building libiberty multilib for mips16 multilibs
--- Comment #1 from rsandifo at gcc dot gnu dot org 2007-04-01 12:24 --- Subject: Bug 31388 Author: rsandifo Date: Sun Apr 1 12:23:54 2007 New Revision: 123398 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123398 Log: gcc/ PR target/31388 * config/mips/mips.md (load_const_gp): New insn. * config/mips/mips.c (mips_split_symbol): Avoid using or creating the MIPS16 GP pseudo register if no_new_pseudos. (mips16_gp_pseudo_reg): Use gen_load_const_gp. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips.c trunk/gcc/config/mips/mips.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31388
[Bug target/31388] ICE building libiberty multilib for mips16 multilibs
--- Comment #2 from rsandifo at gcc dot gnu dot org 2007-04-01 12:25 --- Patch applied to mainline -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31388
[Bug bootstrap/31418] New: Bootstrap failure with -O2 -funroll-loops -funsafe-math-optimizations options on PPC
I get the following error while bootstrapping on PPC with -O2 -funroll-loops -funsafe-math-optimizations: (gcc version 4.3.0 20070401) rm -f stage_current make[3]: Leaving directory `/home/revital/last_bootstrap/build' Comparing stages 2 and 3 warning: ./cc1obj-checksum.o differs warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs Bootstrap comparison failure! ./ipa-inline.o differs -- Summary: Bootstrap failure with -O2 -funroll-loops -funsafe-math- optimizations options on PPC Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: eres at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31418
[Bug c++/31419] New: template user defined conversion operator instantiated for conversion to self
The following code does not compile:
--templcvt.cc
extern int f( int ) ;
class B
{
public:
template< typename T >
operator T const& () const
{
return f( 42 ) ;
}
} ;
B
g()
{
return B() ;
}
-
When invoking "g++ -c templcvt.cc", the compiler outputs the
following error messages:
templcvt.cc: In member function 'B::operator const T&() const [with T =
B]':
templcvt.cc:24: instantiated from here
templcvt.cc:17: error: invalid initialization of reference of type 'const
B&' from expression of type 'int'
Apparently, it is instantiating the template conversion operator
in order to bind the temporary object to the B const& argument
of the (implicit) copy constructor. This dispite §12.3.2.1 "A
conversion function is never used to convert a (possibly
cv-qualified) object to the (possibly cv-qualified) same object
type (or a reference to it),[...]" (and the fact, of course,
that a function template should only be instantiated if the
function is used).
There's a simple work-around: just define an explicit:
operator B const&() const { return *this ; }
as well. But this shouldn't be necessary.
(See also the discussion in comp.std.c++:
http://groups.google.com/group/comp.std.c++/browse_frm/thread/32139b794c433839/#)
--
Summary: template user defined conversion operator instantiated
for conversion to self
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: james dot kanze at gmail 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=31419
[Bug c++/31419] template user defined conversion operator instantiated for conversion to self
--- Comment #1 from fang at csl dot cornell dot edu 2007-04-01 15:38 --- Aside, it looks to me as if operator () returns a reference (const) to a temporary, which is undefined, no? -- fang at csl dot cornell dot edu changed: What|Removed |Added CC||fang at csl dot cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31419
[Bug target/31420] New: CONSTRAINT_LEN is slow on i?86, x86_64
For a -O0 tramp3d-v4.cpp compile, reload and its calls to CONSTRAINT_LEN are on
top of the profiles:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds secondscalls s/call s/call name
3.74 1.34 1.34 265677 0.00 0.00 record_reg_classes
2.96 2.40 1.06 1145706 0.00 0.00 gt_ggc_mx_lang_tree_node
2.62 3.34 0.94 10097098 0.00 0.00 ggc_alloc_stat
2.51 4.24 0.90 2369119 0.00 0.00 walk_tree
2.51 5.14 0.90 323915 0.00 0.00 find_reloads
2.48 6.03 0.89 10110867 0.00 0.00
expand_template_argument_pack
2.29 6.85 0.82 33351577 0.00 0.00 lookup_constraint
2.20 7.64 0.79 16245996 0.00 0.00 ggc_set_mark
1.42 8.15 0.51 6300484 0.00 0.00 mark_set_1
1.42 8.66 0.51 526692 0.00 0.00 retrieve_specialization
1.14 9.07 0.41 32030410 0.00 0.00 insn_constraint_len
[42] 5.00.900.88 323915 find_reloads [42]
0.450.00 18162825/33351577 lookup_constraint [68]
0.230.00 17752937/32030410 insn_constraint_len [106]
At least insn_constraint_len could be inlined:
size_t
insn_constraint_len (enum constraint_num c)
{
switch (c)
{
case CONSTRAINT_Y2: return 2;
case CONSTRAINT_Yi: return 2;
case CONSTRAINT_Ym: return 2;
default: break;
}
return 1;
}
and both, insn_constraint_len and lookup_constraint can be marked pure. For
i686 at least an optimized CONSTRAINT_LEN can be done with
#define CONSTRAINT_LEN(c_,s_) (c_ == 'Y' ? 2 : 1)
--
Summary: CONSTRAINT_LEN is slow on i?86, x86_64
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: compile-time-hog
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: i?86-*-* x86_64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31420
[Bug c++/31419] template user defined conversion operator instantiated for conversion to self
--- Comment #2 from james dot kanze at gmail dot com 2007-04-01 15:42 --- Subject: Re: template user defined conversion operator instantiated for conversion to self On 1 Apr 2007 14:38:52 -, fang at csl dot cornell dot edu <[EMAIL PROTECTED]> wrote: > --- Comment #1 from fang at csl dot cornell dot edu 2007-04-01 15:38 > --- > Aside, it looks to me as if operator () returns a reference (const) to a > temporary, which is undefined, no? There is no operator() in the code. And there is no undefined behavior is the reference is not used. But that's not the point. What the user defined conversion operator does is irrelevant, since it should never even be instantiated. (This is not the actual code in my application, of course. I've simplified it to the maximum.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31419
[Bug fortran/31366] Last record truncated for read after short write, direct access file
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2007-04-01 16:24 --- Subject: Bug 31366 Author: jvdelisle Date: Sun Apr 1 16:23:48 2007 New Revision: 123401 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123401 Log: 2007-04-01 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/31366 * io/transfer.c (read_block_direct): Do not generate error when reading past EOF on a short record that is less than the RECL= specified. 2007-04-01 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/31207 * io/unit.c (close_unit_1): If there are bytes previously written from ADVANCE="no", move to the end before closing. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c trunk/libgfortran/io/unit.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31366
[Bug fortran/31207] advance="no" and tabs
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-04-01 16:24 --- Subject: Bug 31207 Author: jvdelisle Date: Sun Apr 1 16:23:48 2007 New Revision: 123401 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123401 Log: 2007-04-01 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/31366 * io/transfer.c (read_block_direct): Do not generate error when reading past EOF on a short record that is less than the RECL= specified. 2007-04-01 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/31207 * io/unit.c (close_unit_1): If there are bytes previously written from ADVANCE="no", move to the end before closing. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c trunk/libgfortran/io/unit.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31207
[Bug fortran/31366] Last record truncated for read after short write, direct access file
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-04-01 16:29 --- Subject: Bug 31366 Author: jvdelisle Date: Sun Apr 1 16:29:05 2007 New Revision: 123402 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123402 Log: 2007-04-01 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/31366 * gfortran.dg/direct_io_6.f90: New test. 2007-04-01 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/31207 * gfortran.dg/advance_5.f90: New test. * gfortran.dg/advance_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/advance_4.f90 trunk/gcc/testsuite/gfortran.dg/advance_5.f90 trunk/gcc/testsuite/gfortran.dg/direct_io_6.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31366
[Bug fortran/31207] advance="no" and tabs
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-04-01 16:29 --- Subject: Bug 31207 Author: jvdelisle Date: Sun Apr 1 16:29:05 2007 New Revision: 123402 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123402 Log: 2007-04-01 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/31366 * gfortran.dg/direct_io_6.f90: New test. 2007-04-01 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/31207 * gfortran.dg/advance_5.f90: New test. * gfortran.dg/advance_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/advance_4.f90 trunk/gcc/testsuite/gfortran.dg/advance_5.f90 trunk/gcc/testsuite/gfortran.dg/direct_io_6.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31207
[Bug c++/31419] template user defined conversion operator instantiated for conversion to self
--- Comment #3 from fang at csl dot cornell dot edu 2007-04-01 16:57 --- Subject: Re: template user defined conversion operator instantiated for conversion to self > There is no operator() in the code. And there is no undefined > behavior is the reference is not used. But that's not the > point. What the user defined conversion operator does is > irrelevant, since it should never even be instantiated. > > (This is not the actual code in my application, of course. I've > simplified it to the maximum.) Yep, I realize it's irrelevant, which is why I mentioned it as an 'aside'. :) Just brought it up in case the non-reduced version in your original code does actually use it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31419
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #38 from patchapp at dberlin dot org 2007-04-01 17:00 --- Subject: Bug number PR31052 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-04/msg00014.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug target/31420] CONSTRAINT_LEN is slow on i?86, x86_64
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-04-01 18:06 --- Created an attachment (id=13315) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13315&action=view) patch General patch creating an optimized function usable for CONSTRAINT_LEN (without actually generating a inline variant). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31420
[Bug target/31420] CONSTRAINT_LEN is slow on i?86, x86_64
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-04-01 18:15 ---
Created an attachment (id=13316)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13316&action=view)
other patch
And an inlined variant producing
static inline size_t
insn_constraint_len_s (char fc, const char *str ATTRIBUTE_UNUSED)
{
switch (fc)
{
case 'Y':
return 2;
break;
default: break;
}
return 1;
}
for i?86. Looking at other ports the worst case is s390 which has A* and
B* two-letter constraints.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31420
[Bug target/31420] CONSTRAINT_LEN is slow on i?86, x86_64
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-04-01 18:17 --- The latter patch is a 2.5% to 3.5% win for a -O0 tramp3d compile on i686. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31420
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #39 from jvdelisle at gcc dot gnu dot org 2007-04-01 18:32 --- Subject: Bug 31052 Author: jvdelisle Date: Sun Apr 1 18:32:20 2007 New Revision: 123403 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123403 Log: 2007-04-01 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/31052 * io/open.c (test_endfile): Delete this function. (edit_modes): Delete call to test_endfile. (new_unit): Likewise. * io/io.h: Delete prototype for test_endfile. * io/transfer.c (next_record_r): Remove use of test_endfile. (st_read): Add test for end file condition and adjust status. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/io.h trunk/libgfortran/io/open.c trunk/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #40 from jvdelisle at gcc dot gnu dot org 2007-04-01 18:33 --- Subject: Bug 31052 Author: jvdelisle Date: Sun Apr 1 18:33:13 2007 New Revision: 123404 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123404 Log: 2007-04-01 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/31052 * gfortran.dg/namelist_28.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/namelist_28.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug target/31420] CONSTRAINT_LEN is slow on i?86, x86_64
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-04-01 18:40 --- With the second patch applied the profile for -O0 changes to Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls s/call s/call name 3.38 1.15 1.15 265736 0.00 0.00 record_reg_classes 3.17 2.23 1.08 16251625 0.00 0.00 ggc_set_mark 3.08 3.28 1.05 1141302 0.00 0.00 gt_ggc_mx_lang_tree_node 2.99 4.30 1.02 10110867 0.00 0.00 expand_template_argument_pack 2.64 5.20 0.90 323989 0.00 0.00 find_reloads 2.61 6.09 0.89 10099284 0.00 0.00 ggc_alloc_stat 2.23 6.85 0.76 2370417 0.00 0.00 walk_tree 1.82 7.47 0.62 6302869 0.00 0.00 mark_set_1 1.41 7.95 0.48 526692 0.00 0.00 retrieve_specialization so reload is still slow ;) Sill, mine. -- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-01 18:40:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31420
[Bug fortran/31366] [4.2 only] Last record truncated for read after short write, direct access file
-- 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|REOPENED|ASSIGNED Keywords||wrong-code Last reconfirmed|2007-03-26 22:18:42 |2007-04-01 18:56:41 date|| Summary|Last record truncated for |[4.2 only] Last record |read after short write, |truncated for read after |direct access file |short write, direct access ||file http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31366
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- Comment #48 from rth at gcc dot gnu dot org 2007-04-01 19:17 --- Subject: Bug 31169 Author: rth Date: Sun Apr 1 19:17:38 2007 New Revision: 123405 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123405 Log: PR tree-optimization/31169 * tree-vrp.c (extract_range_from_binary_expr) : Drop to varying if the range is outside [0, prec-1]. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug rtl-optimization/31391] [4.3 Regression] undefined label with -O -g due to cfglayout
--- Comment #9 from steven at gcc dot gnu dot org 2007-04-01 19:26 --- Subject: Bug 31391 Author: steven Date: Sun Apr 1 19:26:00 2007 New Revision: 123406 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123406 Log: PR rtl-optimization/31391 * cfgcleanup.c (try_optimize_cfg): If a removed label is turned into a DELETED_LABEL note, and the label is in an empty basic block, update BB_END as well as BB_HEAD. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgcleanup.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31391
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- Comment #49 from rth at gcc dot gnu dot org 2007-04-01 19:26 --- Fixed. -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug c/31421] New: Wrong compilation results with -Os option specified
I'm using arm-elf-gcc compiler, build for cygwin environment (gnuarm.org).
Here is example, which shows wrong results:
//---
#include
#define FPGA_BASE 0x8100
static inline void fpga_write( unsigned short address, unsigned short data )
{
*((volatile unsigned short*)(FPGA_BASE+address)) = data;
asm volatile( "nop" ); /* Slow down IO */
}
int f()
{
unsigned intcounter;
unsigned short* buf = (unsigned short*)((void*)&counter);
memcpy( buf, "test", 4 );
counter++;
fpga_write( 0x6A, buf[0] );
fpga_write( 0x6A, buf[1] );
return 0;
}
//---
I run gcc with following options:
arm-elf-gcc -Wa,-adhls=test.lst -fomit-frame-pointer -Os -Wall -g -c
-march=armv4t -mtune=arm7tdmi -msoft-float -pipe test.c
Gcc produces following listing for my code:
str lr,[sp,#-4]!
sub sp,sp,#4
mov r0,sp
ldr r1,.L3
mov r2,#4
bl memcpy
ldr r3,[sp,#0]
ldrh r1,[sp,#0] ; source of problem. This word is extracted from memory
add r3,r3,#1 ; before actual increment. This is wrong.
mov r2,#-2130706432
str r3,[sp,#0]; Saving incremented value. But least significant word
strh r1,[r2,#106] ; will not be incremented. :(
nop
ldrh r3,[sp,#2] ; All is right here.
strh r3,[r2,#106]
nop
mov r0,#0
add sp,sp,#4
ldmfd sp!,{pc}
Disabling optimisations solves this problem. But in this case binary code will
be noticeably bigger.
--
Summary: Wrong compilation results with -Os option specified
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dednev at pisem dot net
GCC host triplet: i686-cygwin
GCC target triplet: arm-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31421
[Bug c/31422] New: math.h functions generate warnings on newer version of gcc
Hi there. Some very simple code generates a warning when compiled on gcc 4.1.2. The code compiles cleanly, when using gcc 3.4.6 The bug involves the use of fmaxf function that is defined in math.h. First, here is the relevant section: I'm attaching the source file along with the output of the compile command with the -v and -save-temps option. Feel free to let me know what more information is required. Next, this is the command I used to compile this file, along with the results. [EMAIL PROTECTED]:~$ gcc Lab9.c -Wall -o Lab9 -lm Lab9.c: In function printResults: Lab9.c:115: warning: implicit declaration of function fmaxf Lab9.c:115: warning: incompatible implicit declaration of built-in function fmaxf On a machine that has the older version of gcc installed, I do not receive this warning. The code still runs correctly in both cases, however. -- Summary: math.h functions generate warnings on newer version of gcc Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mjt9 at geneseo dot edu GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31422
[Bug c/31422] math.h functions generate warnings on newer version of gcc
--- Comment #1 from mjt9 at geneseo dot edu 2007-04-01 20:14 --- Created an attachment (id=13317) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13317&action=view) compiler output with the -v flag -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31422
[Bug c/31421] Wrong compilation results with -Os option specified
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-04-01 20:15 --- You are violating C aliasing rules as you are accessing count both as integer and short. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31421
[Bug c/31422] math.h functions generate warnings on newer version of gcc
--- Comment #2 from mjt9 at geneseo dot edu 2007-04-01 20:16 --- Created an attachment (id=13318) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13318&action=view) original source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31422
[Bug c/31422] math.h functions generate warnings on newer version of gcc
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-04-01 20:23 --- You need to build with -std=c99 (see the manual page for fmax) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31422
[Bug target/31420] CONSTRAINT_LEN is slow on i?86, x86_64
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-04-01 20:48 --- regclass is also slow. insn-select branch is supposed to fix it. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||matz at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31420
[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-04-01
21:36 ---
Subject: Re: FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test
> Dave, unfortunately all the other linux targets are fine, therefore we have
> very big troubles figuring out what is happening on hppa only. Given that, as
> far as I know, no one among the v3 maintainers has access to hppa machines,
> I'm
> afraid that you have to do most of the investigation work here, despite the PR
> being categorized as libstdc++-v3... Just follow get_date... (remember to
> build
> the library -O0 -g3)
Ok, I built the library with -O0 -g3 and stepped through trying to find
the failure.
It appears that the failure occurs here:
std::ctype::do_narrow (this=0x101f80, __wc=35199, __dfault=42 '*')
at ctype_members.cc:221
221 do_narrow(wchar_t __wc, char __dfault) const
Current language: auto; currently c++
(gdb) p/x __wc
$20 = 0x897f
(gdb) step
223 if (__wc >= 0 && __wc < 128 && _M_narrow_ok)
(gdb)
226 __c_locale __old = __uselocale(_M_c_locale_ctype);
(gdb)
228 const int __c = wctob(__wc);
(gdb)
230 __uselocale(__old);
(gdb)
232 return (__c == EOF ? __dfault : static_cast(__c));
(gdb) p __c
$22 = -1
The backtrace is:
(gdb) bt
#0 std::ctype::do_narrow (this=0x101f80, __wc=35199, __dfault=42 '*')
at ctype_members.cc:232
#1 0x00014a30 in std::__ctype_abstract_base::narrow (this=0x101f80,
__c=35199, __dfault=42 '*')
at
/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/bits/locale_facets.h:327
#2 0x00035c94 in std::time_get > >::_M_extract_num (this=0x101f80, __beg=
{> = {}, _M_sbuf = 0x101518, _M_c =
704643144}, __end=
{> = {}, _M_sbuf = 0x897f, _M_c = 14},
[EMAIL PROTECTED],
__min=-1073172736, __max=0, __len=951080, [EMAIL PROTECTED], [EMAIL PROTECTED])
at
/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/bits/locale_facets.tcc:2040
#3 0x00039194 in std::time_get > >::_M_extract_via_format (this=0x101f80, __beg=
{> = {}, _M_sbuf = 0x101518, _M_c =
704643144}, __end=
{> = {}, _M_sbuf = 0x897f, _M_c = 14},
[EMAIL PROTECTED],
[EMAIL PROTECTED], __tm=0x0, __format=0xe8328)
at
/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/bits/locale_facets.tcc:1973
#4 0x000395d0 in std::time_get > >::do_get_date (this=0x101f80, __beg=
{> = {}, _M_sbuf = 0x101518, _M_c =
704643144}, __end=
{> = {}, _M_sbuf = 0x897f, _M_c = 14},
[EMAIL PROTECTED],
[EMAIL PROTECTED], __tm=0x0)
at
/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/bits/locale_facets.tcc:2163
#5 0x000343cc in std::time_get > >::get_date (this=0x101f80, __beg=
{> = {}, _M_sbuf = 0x101518, _M_c =
704643144}, __end=
{> = {}, _M_sbuf = 0x897f, _M_c = 14},
[EMAIL PROTECTED],
[EMAIL PROTECTED], __tm=0x0)
at
/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/bits/locale_facets.h:3147
#6 0x00010680 in test01 ()
at
/home/dave/gnu/gcc-4.2/gcc/libstdc++-v3/testsuite/22_locale/time_get/get_date/wchar_t/4.cc:54
#7 0x00010810 in main ()
at
/home/dave/gnu/gcc-4.2/gcc/libstdc++-v3/testsuite/22_locale/time_get/get_date/wchar_t/4.cc:63
The failure to narrow the character causes __err to get set here:
/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/bits/locale
_facets.tcc:2055.
This causes __tmperr to get set in 'Y' case. This causes __err to
get set again here:
/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/bits/locale
_facets.tcc:2017.
This causes the VERIFY failure.
Is the EOF result expected for the wctob call?
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413
[Bug c++/31423] New: Improve upon "invalid use of member (did you forget the '&' ?)"
For the program
struct C {
int f() { return 1; }
};
int f(C &c) {
return ( 1 == c.f );
}
we currently issue
In function 'int f(C&)':
6: error: invalid use of member (did you forget the '&' ?)
Basically, my thought is that whenever we encounter a comparison of a
member function c.f with a value that is compatible with its return type,
the author of the code probably ment to write c.f() instead of &c.f, so
the error message could propose the former.
Specifically, I suggest to issue
error: invalid use of member (did you forget the "()" ?)
instead of
error: invalid use of member (did you forget the '&' ?)
when the return type of the function c.f is an integer type and we
compare against an integer constant as per my original example.
--
Summary: Improve upon "invalid use of member (did you forget the
'&' ?)"
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gerald at pfeifer dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31423
[Bug fortran/30872] Bogus "size of variable is too large"
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-01 23:11 ---
This fixes it and regtests on x86_ia64/FC5. The arithmetic for finding the
offset to a rank>1 element was plain wrong.
I will submit asap.
Paul
Index: gcc/fortran/expr.c
===
*** gcc/fortran/expr.c (revision 123382)
--- gcc/fortran/expr.c (working copy)
*** find_array_element (gfc_constructor *con
*** 899,904
--- 899,906
int i;
mpz_t delta;
mpz_t offset;
+ mpz_t span;
+ mpz_t tmp;
gfc_expr *e;
try t;
*** find_array_element (gfc_constructor *con
*** 907,912
--- 909,916
mpz_init_set_ui (offset, 0);
mpz_init (delta);
+ mpz_init (tmp);
+ mpz_init_set_ui (span, 1);
for (i = 0; i < ar->dimen; i++)
{
e = gfc_copy_expr (ar->start[i]);
*** find_array_element (gfc_constructor *con
*** 930,936
--- 934,946
}
mpz_sub (delta, e->value.integer, ar->as->lower[i]->value.integer);
+ mpz_mul (delta, delta, span);
mpz_add (offset, offset, delta);
+
+ mpz_set_ui (tmp, 1);
+ mpz_add (tmp, tmp, ar->as->upper[i]->value.integer);
+ mpz_sub (tmp, tmp, ar->as->lower[i]->value.integer);
+ mpz_mul (span, span, tmp);
}
if (cons)
*** find_array_element (gfc_constructor *con
*** 949,954
--- 959,966
depart:
mpz_clear (delta);
mpz_clear (offset);
+ mpz_clear (span);
+ mpz_clear (tmp);
if (e)
gfc_free_expr (e);
*rval = cons;
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2007-02-20 16:50:46 |2007-04-01 23:11:48
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30872
[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test
--- Comment #4 from pcarlini at suse dot de 2007-04-01 23:23 --- Hi Dave. I tell you the first things I see on x86: do_get_date calls _M_extract_via_format. In the latter there is a loop over __i, from 0 to __len == 11: the char array __format is parsed. The first two times 'if (__ctype.narrow(__format[__i], 0) == '%')' is executed (that is, for i == 0, i == 1, where __format[0] == 0x897f (35199 base 10) and __format[1] == 0x5143), narrow returns -1 and we move ahead, that's expected, we are looking for a '%'. The third time a '%' is found, and then __c == 'Y'. I would suggest checking the contents of __format when _M_extract_via_format starts, that is verifying that it begins with the exact same two chars of wstr in the C++ source and therefore L'%' and L'Y'. Anyway, by the time we switch to 'Y', we moved ahead 2 positions in __format (__i == 2) and bumped two times __beg. Therefore _M_extract_num will start reading the third char of wstr, and then the other 3 forming a year L'2' L'0' L'0' L'3'... Note that in general, wctob can well return -1, every time there is no plain char equivalent of a multi byte char. In the testcase happens for the first two chars of __format, then finally we find L'%' and L'Y' which have of course '%' and 'Y' as equivalent. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413
[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test
--- Comment #5 from pcarlini at suse dot de 2007-04-01 23:34 --- (In reply to comment #4) > I would suggest checking the contents of __format when _M_extract_via_format > starts, that is verifying that it begins with the exact same two chars of wstr > in the C++ source and therefore L'%' and L'Y'. Sorry about the stupid typo: L'%' and L'Y' are of course the *third* and *fourth* char of __format. The first two are identical to the first two chars of wstr. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413
[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2007-04-02 00:16 --- Subject: Re: FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test > (In reply to comment #4) > > I would suggest checking the contents of __format when _M_extract_via_format > > starts, that is verifying that it begins with the exact same two chars of > > wstr > > in the C++ source and therefore L'%' and L'Y'. > > Sorry about the stupid typo: L'%' and L'Y' are of course the *third* and > *fourth* char of __format. The first two are identical to the first two chars > of wstr. I'm seeing L'%' and L'Y' as the first two characters in __format: (gdb) p __format[0] $34 = 37 (gdb) p __format[1] $35 = 89 Narrowing only occurs in just the one case that I mentioned (first character of wstr). Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413
[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test
--- Comment #7 from pcarlini at suse dot de 2007-04-02 00:31 --- (In reply to comment #6) > I'm seeing L'%' and L'Y' as the first two characters in __format: > (gdb) p __format[0] > $34 = 37 > (gdb) p __format[1] > $35 = 89 That means that something is going badly wrong when __dates[0] is set in do_get_date. You should follow __tp._M_date_formats(__dates), before the _M_extract_via_format call. And going back as much as necessary. Anyway, I would suggest you finding somewhere an x86, x86_64, ia64, powerpc or s390 system and have that as reference, ready at hand. Otherwise, the debugging will proceed too slowly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413
[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test
--- Comment #8 from pcarlini at suse dot de 2007-04-02 00:53 ---
One last remark: when something having to do with named locales doesn't work,
often I find myself checking whether corresponding "C" code works. In this
case, if __format is wrong, which means apparently that _M_data->_M_date_format
is wrong, I suggest preparing a plain "C" snippet equivalent to the code in
config/locale/gnu/time_members.cc which sets _M_data->_M_date_format, something
like:
loc = newlocale(1 << LC_ALL, __s, 0);
union { char *__s; wchar_t *__w; } __u;
__u.__s = __nl_langinfo_l(_NL_WD_FMT, loc);
const wchar_t* pp = __u.__w;
and inspect pp. Here it's fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413
[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test
--- Comment #9 from pcarlini at suse dot de 2007-04-02 00:54 --- Of course: const char* __s = "zh_TW"; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413
[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2007-04-02
03:36 ---
Subject: Re: FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test
> --- Comment #8 from pcarlini at suse dot de 2007-04-02 00:53 ---
> One last remark: when something having to do with named locales doesn't work,
> often I find myself checking whether corresponding "C" code works. In this
> case, if __format is wrong, which means apparently that
> _M_data->_M_date_format
> is wrong, I suggest preparing a plain "C" snippet equivalent to the code in
> config/locale/gnu/time_members.cc which sets _M_data->_M_date_format,
> something
> like:
>
> loc = newlocale(1 << LC_ALL, __s, 0);
>
> union { char *__s; wchar_t *__w; } __u;
> __u.__s = __nl_langinfo_l(_NL_WD_FMT, loc);
>
> const wchar_t* pp = __u.__w;
Thanks for the tip. The following doesn't work on hppa but
does on x86:
#include
#include
#include
wchar_t *
foo (void)
{
char *__s = "zh_TW";
wchar_t *pp;
locale_t loc;
union { char *__s; wchar_t *__w; } __u;
loc = newlocale(1 << LC_ALL, __s, 0);
__u.__s = nl_langinfo_l(_NL_WD_FMT, loc);
pp = __u.__w;
return pp;
}
int
main ()
{
wchar_t *pp;
pp = foo ();
return 0;
}
Displaying the return value from the call to foo yields
(gdb) p ((wchar_t *)$ret0)[0]
$1 = 37
So, I think the problem is in nl_langinfo_l.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413
gcc-3.4.6 and sh-unknown-linux-gnu build error
There was a phenomenon that the multi library was not able to be made when
gcc-3.4.6 was Bilded
with sh-unknown-linux-gnu.
The cause
In config/sh/linux.h,
#if defined (__SH4E__) || defined(__SH4__) ---> Original
#if defined (__SH3E__) || defined(__SH4__) ---> Chenged
It failed in making the multi library becoming.
The influence is still uncertain though there is a similar
description in linux-unwind.h also as for gcc-4.1.2.
It confirms and also when it is bug, it reports.
cut hear---
diff -ruN gcc-3.4.6.orig/gcc/config/sh/linux.h gcc-3.4.6/gcc/config/sh/linux.h
--- gcc-3.4.6.orig/gcc/config/sh/linux.h2004-01-12 11:29:13.0
+0900
+++ gcc-3.4.6/gcc/config/sh/linux.h 2006-08-09 17:24:32.0 +0900
@@ -182,7 +182,7 @@
/* MD_FALLBACK_FRAME_STATE_FOR is not yet defined for SHMEDIA. */
#else /* defined (__SH5__) */
-#if defined (__SH3E__) || defined (__SH4__)
+#if defined (__SH4E__) || defined (__SH4__)
#define SH_FALLBACK_FRAME_FLOAT_STATE(SC, FS, CFA) \
do { \
int i_, r_;
\
cut hear---
[Bug target/19492] can not build crosscompiler for solaris2.8 (when building libstdc++ - error wcslen...:Link tests are not allowed after GCC_NO_EXECUTABLES)
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-04-02 06:03 --- Use --with-sysroot to configure GCC for cross, it makes everything easier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19492
[Bug rtl-optimization/31391] [4.3 Regression] undefined label with -O -g due to cfglayout
--- Comment #10 from steven at gcc dot gnu dot org 2007-04-02 06:41 --- . -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31391
