REG_OK_STRICT and EXTRA_CONSTRAINT
Some ports, notably MMIX, are using different definitions of EXTRA_CONSTRAINT depending on REG_OK_STRICT. This can be a bug, because the same instruction may be considered invalid in reload.c and valid by recog.c. The opposite would be bad because after reload everything must still adhere to the non-strict RTL definition. Luckily it cannot happen, because the strict definition are (guess what) more strict. I'm considering changing it to use the strict definition if "reload_in_progress || reload_completed". I'm more comfortable with the change because of this definition in i386/predicates.md: if (reload_in_progress || reload_completed) return REG_OK_FOR_INDEX_STRICT_P (op); else return REG_OK_FOR_INDEX_NONSTRICT_P (op); So I would apply this patch to addressing-modes branch but I'd appreciate advice: is the patch safe, or is there some case where reload.c looks at constraints and reload_in_progress == 0? /* When checking for an address, we need to handle strict vs. non-strict register checks. Don't use address_operand, but instead its equivalent (its callee, which it is just a wrapper for), memory_operand_p and the strict-equivalent strict_memory_address_p. */ if (c == 'U') return - strict + reload_in_progress || reload_completed ? strict_memory_address_p (Pmode, x) : memory_address_p (Pmode, x); (Plus the removal of the strict argument, and so on). Paolo
attempt to use poisoned "CONST_COSTS"
Hello everyone,
I am upgrading a cross compiler from 3.2 to 3.4.6
I had to change some of the TARGET description macros
in target.h file
for otherwise while building i am getting "attempt to
use poisoned" errors
Presently what is written in target.h is
1. #define CPP_PREDEFINES \
"-Dtargetname -D__targetname__ -Amachine=targetname"
corresponding macro in 3.4.6 is
"TARGET_CPU_CPP_BUILTINS"
2. #define CONST_COSTS(RTX, CODE, OUTER_CODE) \
case CONST_INT: \
return target_const_costs (RTX, OUTER_CODE);
\
case CONST: \
return 5; \
case LABEL_REF: \
return 1; \
case SYMBOL_REF:\
return ((TARGET_SMALL_MODEL)? 2: 3);\
case CONST_DOUBLE: \
return 10;
i dont know the corresponding macro in 3.4.6
3. #define ADDRESS_COST(RTX) 1
corresponding macro in 3.4.6 is "int
TARGET_ADDRESS_COST (rtx address)"
4. #define RTX_COSTS(X, CODE, OUTER_CODE) \
case MULT:
\
return COSTS_N_INSNS (2);
\
case DIV: \
case UDIV: \
case MOD: \
case UMOD: \
return COSTS_N_INSNS (30);
\
case FLOAT: \
case FIX: \
return COSTS_N_INSNS (100);
corresponding macro in 3.4.6 is "bool
TARGET_RTX_COSTS (rtx x, int code, int outer_code, int
*total)"
5.#define ASM_GLOBALIZE_LABEL(STREAM,NAME)\
do \
{ \
fputs ("\t.globl ", STREAM);\
assemble_name (STREAM, NAME); \
fputs ("\n", STREAM); \
} \
while (0)
corresponding macro in 3.4.6 is "void
TARGET_ASM_GLOBALIZE_LABEL (FILE *stream, const char
*name)"
Now to my problem :
except for TARGET_CPU_CPP_BUILTINS i dont know how
to rewrite the existing macros for 3.4.6
Can anybody help me in this regard?
Thanks in advance
Regards,
Shafi.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: attempt to use poisoned "CONST_COSTS"
2. #define CONST_COSTS(RTX, CODE, OUTER_CODE) \ case CONST_INT: \ return target_const_costs (RTX, OUTER_CODE); \ case CONST: \ return 5; \ case LABEL_REF: \ return 1; \ case SYMBOL_REF:\ return ((TARGET_SMALL_MODEL)? 2: 3);\ case CONST_DOUBLE: \ return 10; i dont know the corresponding macro in 3.4.6 It is now merged into RTX_COSTS. You should look at a small back-end, e.g. pdp11, and see how to rewrite these macros into functions (target hooks). Paolo
Re: REG_OK_STRICT and EXTRA_CONSTRAINT
On Thu, 24 Aug 2006, Paolo Bonzini wrote: > Some ports, notably MMIX, are using different definitions of > EXTRA_CONSTRAINT depending on REG_OK_STRICT. This can be a bug, because > the same instruction may be considered invalid in reload.c and valid by > recog.c. When I wrote that code, accounting for REG_OK_STRICT was not a bug, but TRT. (I'm about two months behind on mailing list reading, so I guess things may have changed as things tend to do.) > So I would apply this patch to addressing-modes branch but I'd > appreciate advice: is the patch safe, or is there some case where > reload.c looks at constraints and reload_in_progress == 0? My opinion is that regtesting and checking that the same assembly is emitted before and after the patch would be sufficient testing... It's definitely not safe without. ;) brgds, H-P
make check glitch
I have been able to use the command...
make -k check RUNTESTFLAGS='--target_board "unix{,-m64}"'
to check my multilib gcc trunk build on Darwin ppc from within
the darwin_objdir/gcc directory of the build tree. However
this doesn't seem to allow both the -m32 and -m64 testsuite
runs for the other libs like libstdc++ and libgomp, etc. If
I run the same command from the toplevel of the darwin_objdir
directory, the make check bails out with...
make all-recursive
Making all in testsuite
make[7]: Nothing to be done for `all'.
true DO=all multi-do # make
make[2]: *** [check-recursive] Error 1
make[2]: Target `check' not remade because of errors.
make[1]: *** [check-target-libgomp] Error 2
make[1]: Target `check-target' not remade because of errors.
make: *** [do-check] Error 2
make: Target `check' not remade because of errors.
Am I doing something wrong here or is there a glitch in doing
a full multilib make check on current gcc trunk? Thanks for
any insights in advance.
Jack
Re: REG_OK_STRICT and EXTRA_CONSTRAINT
Hans-Peter Nilsson wrote: Some ports, notably MMIX, are using different definitions of EXTRA_CONSTRAINT depending on REG_OK_STRICT. This can be a bug, because the same instruction may be considered invalid in reload.c and valid by recog.c. When I wrote that code, accounting for REG_OK_STRICT was not a bug, but TRT. (I'm about two months behind on mailing list reading, so I guess things may have changed as things tend to do.) No, this is just a branch so don't worry. Anyway, I was not meaning to *not* account for anything, but just to replace REG_OK_STRICT with checks on reload_in_progress and reload_completed. I understand the semantics that you wanted for 'U'. The bug may be that in some cases, 'U' is checked for memory_address_p instead of strict_memory_address_p even after reload, in particular when it is recog.c that is constraining the operands. My opinion is that regtesting and checking that the same assembly is emitted before and after the patch would be sufficient testing... It's definitely not safe without. ;) Okay. Paolo
Re: attempt to use poisoned "CONST_COSTS"
You should look at a small back-end, e.g. pdp11, and see how to rewrite these macros into functions (target hooks). Its been a great help... thanks for the direction. When i looked into the machine macros of GNU supported processors i found that all of the macros previously defined in target.h in now defined in target.c in gcc 3.4.6 Not all, just several of them. Does that mean that i need to re write my target.h and target.c file for the migration of the compiler? Just to move code from target.h to target.c. Paolo
Re: attempt to use poisoned "CONST_COSTS"
[no private mail] Just to move code from target.h to target.c. Paolo I didnt get you? Do you mean to say that i should also move the code to stick to standard ? You should move code from target.h to target.c, or it won't compile. Macros became "target hooks" defined in the target.c file. Again, look at a simple back-end to see how it's done. Paolo
Re: sh64 support
Joern RENNECKE <[EMAIL PROTECTED]> wrote: > My simulator now segfaults for every single execution test built with > mainline; when I try gdb, it also segfaults, > somewhere in the dwarf handling code. > Unless someone comes up with a viable concept how to maintain sh64 > support in gcc, I think we have to deprecate > it now, since at the time of the gcc 4.3 release it can be expected to > have bitrotted too much to be more useful than > or even as useful as a vintage release. I agree with Joern about the disastrous status of the simulator test, though not every execution tests fail in my environment: === g++ Summary === # of expected passes12270 # of unexpected failures235 # of unexpected successes 1 # of expected failures 65 # of unresolved testcases 50 # of unsupported tests 140 === gcc Summary === # of expected passes38606 # of unexpected failures610 # of unexpected successes 2 # of expected failures 73 # of unresolved testcases 42 # of untested testcases 28 # of unsupported tests 413 === libstdc++ Summary === # of expected passes2390 # of unexpected failures491 # of unexpected successes 1 # of expected failures 10 # of unsupported tests 153 Compiler version: 4.2.0 20060823 (experimental) Platform: sh64-unknown-elf configure flags: --host=i686-pc-linux-gnu --target=sh64-unknown-elf --with-ld=/usr/local/bin/sh64-unknown-elf-ld --with-as=/usr/local/bin/sh64-unknown-elf-as --disable-libssp --with-headers --with-newlib --disable-gdb --enable-languages=c,c++ Perhaps it's because I gave up the unified tree and use older sim and binutils. Oddly the result of the regtest on sh64-unknown-linux-gnu looks not so broken: http://gcc.gnu.org/ml/gcc-testresults/2006-08/msg01073.html Regards, kaz
Fwd: Re: attempt to use poisoned "CONST_COSTS"
Note: forwarded message attached. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- Begin Message --- Hai, > > i dont know the corresponding macro in > 3.4.6 > > It is now merged into RTX_COSTS. > > You should look at a small back-end, e.g. pdp11, and > see how to rewrite > these macros into functions (target hooks). > Its been a great help... thanks for the direction. When i looked into the machine macros of GNU supported processors i found that all of the macros previously defined in target.h in now defined in target.c in gcc 3.4.6 Does that mean that i need to re write my target.h and target.c file for the migration of the compiler? regards, shafi __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- End Message ---
re: make check glitch
I should add that I see the same problem if I execute...
make -k check RUNTESTFLAGS='--target_board "unix{,-m32}"'
...from the toplevel of the linux_obj directory on gcc trunk
built on a x86_64 Fedora Core 5 machine. The behavior is the
same as on darwin. If I execute the above command from the
gcc subdirectory, the make check completes. This is preventing
any testing of the the libraries in gcc for -m32 on x86_64 or
-m64 on Darwin ppc.
Jack
FW: ostringstream: problems with str() function
Hi,
I had a crash in our software, which occured randomly. The valgrind logs
and the stack trace pointed to a code snippet, which uses ostringstream
for data conversion. (int -> string, float -> string, double-> string).
After changing the ostringstream conversion to sprintf, the crash in the
application no more occured and the valgrind log was clear as well. It
seems the problem is in the str() function of ostringstream.
Consider the following test program in order to reproduce the bug:
#include
#include
#include
#include
#include
int main()
{
std::vector v;
{
std::ostringstream sstr;
sstr << (double)1.12;
v.push_back(sstr.str());
}
return 1;
}
The problem occured with gcc 3.4.2 and 3.4.4 compilers with -O2
optimization. Test program had been running both on 32 and 64 bit
architecture.
With O1 and O0 no problems was logged by valgrind. 3.2 and 4.0 compilers
the program was bug-free as well.
$ g++ -g -O2 -D__STL_DEBUG -DDEBUG test.c
valgrind tool signs the following problems:
==5443== Conditional jump or move depends on uninitialised value(s)
==5443==at 0x11CD3445: std::string::string(std::string const&) (in
/usr/lib64/libstdc++.so.6.0.7)
==5443==by 0x401907: std::vector
>::_M_insert_aux(__gnu_cxx::__normal_iterator > >, std::string
const&) (new:92)
==5443==by 0x40152E: main (stl_vector.h:330)
==5443==
==5443== Conditional jump or move depends on uninitialised value(s)
==5443==at 0x401585: main (basic_string.h:215)
==5443==
==5443== Conditional jump or move depends on uninitialised value(s)
==5443==at 0x401427: main (basic_string.h:215)
==5443==
==5443== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 10 from 5)
==5443== malloc/free: in use at exit: 0 bytes in 0 blocks.
==5443== malloc/free: 3 allocs, 3 frees, 574 bytes allocated.
==5443== For counts of detected errors, rerun with: -v
==5443== No malloc'd blocks -- no leaks are possible.
Do you have any idea for this issue?
Thanks and regards,
Laszlo Jordan
Re: test for excess errors
On Aug 23, 2006, at 4:43 PM, Jack Howarth wrote: --- gcc-4.2-20060822/gcc/testsuite/lib/prune.exp.org2006-08-23 18:33:56.0 -0400 +++ gcc-4.2-20060822/gcc/testsuite/lib/prune.exp2006-08-23 18:41:28.0 -0400 @@ -43,6 +43,7 @@ regsub -all "(^|\n)\[^\n\]*file path prefix \[^\n\]* never used" $text "" text regsub -all "(^|\n)\[^\n\]*linker input file unused since linking not done" $text "" text +regsub -all "(^|\n)can't find atom for N_GSYM stabs \[^\n\]* in \[^\n\]*" $text "" text #send_user "After:$text\n" return $text ...successfully suppresses the ld64 linker warnings currently being generated on Darwin for gfortran. Could you please file a PR for the bug and put a pointer in the code to that PR so that we can know when we can remove it, thanks.
Re: test for excess errors
Mike,
I just created PR28837 with the patch to prune.exp that
prunes the ld64 warnings. I have only tested this with the
core gcc at the moment because I can't get...
make -k check RUNTESTFLAGS='--target_board "unix{,-m64}"'
...to work from the toplevel of the darwin_obj directory...
http://gcc.gnu.org/ml/gcc/2006-08/msg00454.html
I'll probably file a PR on that as well as soon as someone
who really understands the dejagnu testsuite framework can
confirm that it really is a bug (don't see how it can't be
one though).
Jack
Re: make check glitch
On Thu, Aug 24, 2006 at 09:28:11AM -0400, Jack Howarth wrote:
> I should add that I see the same problem if I execute...
>
> make -k check RUNTESTFLAGS='--target_board "unix{,-m32}"'
>
> ...from the toplevel of the linux_obj directory on gcc trunk
> built on a x86_64 Fedora Core 5 machine. The behavior is the
> same as on darwin. If I execute the above command from the
> gcc subdirectory, the make check completes. This is preventing
> any testing of the the libraries in gcc for -m32 on x86_64 or
> -m64 on Darwin ppc.
It works for me on RHEL 4 U4:
http://gcc.gnu.org/ml/gcc-testresults/2006-08/msg01064.html
I am using RUNTESTFLAGS=--target_board 'unix{-m32,}'.
H.J.
Re: test for excess errors
On Thu, Aug 24, 2006 at 12:02:25PM -0400, Jack Howarth wrote:
> Mike,
>I just created PR28837 with the patch to prune.exp that
> prunes the ld64 warnings. I have only tested this with the
> core gcc at the moment because I can't get...
>
> make -k check RUNTESTFLAGS='--target_board "unix{,-m64}"'
>
> ...to work from the toplevel of the darwin_obj directory...
Should be
make -k check RUNTESTFLAGS='--target_board="unix{,-m64}"'
with the equals sign; does it work that way? Also, I always use it
with the double quotes on the outside, single quotes on the inside:
make -k check RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'"
This stuff is all magic to me.
Janis
Re: test for excess errors
Janis,
THANKS! Using either...
make -k check RUNTESTFLAGS="--target_board=unix'{-m32,}'"
or
make -k check RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'"
..works from the toplevel directory (at least for x86_64
on Fedora Core 5...I'll try darwin when I get home to my G5).
Jack
ps I don't see anything in gcc/gcc/doc when I grep...
grep make * | grep check | grep target
...that covers running both 32-bit and 64-bit tests on
multilib systems. With the rise of 64-bit platforms, it
might be good to add a blurb somewhere in the docs.
Re: REG_OK_STRICT and EXTRA_CONSTRAINT
On Thu, 24 Aug 2006, Paolo Bonzini wrote: > Anyway, I was not meaning to *not* account for anything, but just to > replace REG_OK_STRICT with checks on reload_in_progress and > reload_completed. I understand the semantics that you wanted for 'U'. > > The bug may be that in some cases, 'U' is checked for memory_address_p > instead of strict_memory_address_p even after reload, in particular when > it is recog.c that is constraining the operands. If so, not more buggy than other targets that use REG_OK_STRICT a bit more indirectly (like using REG_OK_FOR_BASE_P directly or indirectly in their EXTRA_CONSTRAINT or GO_IF_LEGITIMATE_ADDRESS). Some history I found on this change: http://gcc.gnu.org/ml/gcc-patches/2001-12/msg02585.html> http://gcc.gnu.org/ml/gcc-patches/2001-12/msg02501.html>. Sorry I don't remember more, in particular not where I got the idea to choose between strict_memory_address_p and memory_address_p. I had the flu at the time, so I might have actually found it up myself. :-) If the general replacement of REG_OK_STRICT is indeed reload_in_progress || reload_completed, then the substitution *should* of course be in principle be correct (as in: subject to testing. ;) brgds, H-P
Re: FW: ostringstream: problems with str() function
Jordan, Laszlo (GE Healthcare) wrote:
Hi,
I had a crash in our software, which occured randomly. The valgrind logs
and the stack trace pointed to a code snippet, which uses ostringstream
for data conversion. (int -> string, float -> string, double-> string).
After changing the ostringstream conversion to sprintf, the crash in the
application no more occured and the valgrind log was clear as well. It
seems the problem is in the str() function of ostringstream.
Consider the following test program in order to reproduce the bug:
#include
#include
#include
#include
#include
int main()
{
std::vector v;
{
std::ostringstream sstr;
sstr << (double)1.12;
v.push_back(sstr.str());
}
return 1;
}
The problem occured with gcc 3.4.2 and 3.4.4 compilers with -O2
optimization. Test program had been running both on 32 and 64 bit
architecture.
Can't reproduce neither with gcc-3.4.3 on Linux/x86 nor on AIX.
Michael
Re: FW: ostringstream: problems with str() function
On Thu, Aug 24, 2006 at 04:36:22PM +0200, Jordan, Laszlo (GE Healthcare) wrote:
> Hi,
>
> I had a crash in our software, which occured randomly. The valgrind logs
> and the stack trace pointed to a code snippet, which uses ostringstream
> for data conversion. (int -> string, float -> string, double-> string).
> After changing the ostringstream conversion to sprintf, the crash in the
> application no more occured and the valgrind log was clear as well. It
> seems the problem is in the str() function of ostringstream.
> Consider the following test program in order to reproduce the bug:
>
> #include
> #include
> #include
> #include
> #include
>
> int main()
> {
>
> std::vector v;
> {
> std::ostringstream sstr;
> sstr << (double)1.12;
> v.push_back(sstr.str());
> }
>
> return 1;
> }
I used the exact command line you used, with g++ 3.4.2:
> $ g++ -g -O2 -D__STL_DEBUG -DDEBUG test.c
but I am not seeing the valgrind bug that you are seeing.
Re: = {0} in bss?
Paul Brook <[EMAIL PROTECTED]> writes:
> On Tuesday 22 August 2006 20:14, Mike Stump wrote:
> > I hate to even bring this up, but... should things like:
> >
> >int m[1 << 27] = {0};
> >
> > be put in .bss? I'm tempted to say no, if you want that, you have to
> > remove {0}.
>
> What makes you say this?
>
> Given that C requires global variables without explicit initialisers be zero
> initialised I would find it surprising if adding explicit zero initialisation
> effected my program in any way.
One difference that it makes is that if you don't have the explicit
initializer, you could still write
int m[1 << 27];
in a different translation unit; but if you do, it will produce a
duplicate symbol error in the linker. (Assuming -fcommon, and
-fno-zero-initialized-in-bss.)
Re: test for excess errors
[EMAIL PROTECTED] (Jack Howarth) writes: >Is it the expected behavior for dejagnu to always report warnings > as errors in the "test for excess errors" check? Is this a design > decision or just how dejagnu currently works? I ask because the > current output of "test for excess errors" when a FAIL occurs can > be inaccurate. With -m64 on Darwin we currently get a significant number > of false positives in the fortran testsuite due to linker warnings being > mistaken for errors. Thanks in advance for any clarifications. Yes, it's a design decision. You wouldn't want cc1plus: segmentation fault to be ignored, even if the compiler apparently successfully built the testcase.
Re: mismatched parentheses in reload1.c
>
> else if (rld[r].out_reg == 0
>&& rld[r].in != 0
>&& ((REG_P (rld[r].in)
> && REGNO (rld[r].in) >= FIRST_PSEUDO_REGISTER
> && !REGNO_REG_SET_P (®_has_output_reload,
> REGNO (rld[r].in))
>|| (REG_P (rld[r].in_reg)
>&& !REGNO_REG_SET_P (®_has_output_reload,
> REGNO (rld[r].in)
>&& ! reg_set_p (rld[r].reg_rtx, PATTERN (insn)))
>
Sadly there is yet another typo in this particular change (I didn't
noticed even after proofreading the patch again after Paolo's original
mail). It is causing the enable checking bootstrap fialures.
I've committed the attached patch and I do apologize^2 for this screwup.
Honza
Index: ChangeLog
===
*** ChangeLog (revision 116383)
--- ChangeLog (working copy)
***
*** 1,5
--- 1,9
2006-08-24 Jan Hubicka <[EMAIL PROTECTED]>
+ * reload1.c (emit_reload_insns): Fix yet another typo in my patch.
+
+ 2006-08-24 Jan Hubicka <[EMAIL PROTECTED]>
+
PR debug/26881
* cgraph.c: Fix comments.
(cgraph_varpool_mark_needed_node): Mark only variables not already
Index: reload1.c
===
*** reload1.c (revision 116383)
--- reload1.c (working copy)
*** emit_reload_insns (struct insn_chain *ch
*** 7394,7400
REGNO (rld[r].in)))
|| (REG_P (rld[r].in_reg)
&& !REGNO_REG_SET_P (®_has_output_reload,
! REGNO (rld[r].in
&& ! reg_set_p (rld[r].reg_rtx, PATTERN (insn)))
{
int nregno;
--- 7394,7400
REGNO (rld[r].in)))
|| (REG_P (rld[r].in_reg)
&& !REGNO_REG_SET_P (®_has_output_reload,
! REGNO (rld[r].in_reg
&& ! reg_set_p (rld[r].reg_rtx, PATTERN (insn)))
{
int nregno;
Re: FW: ostringstream: problems with str() function
On Thu, Aug 24, 2006 at 04:36:22PM +0200, Jordan, Laszlo (GE Healthcare) wrote:
>
> Hi,
>
> I had a crash in our software, which occured randomly. The valgrind logs
> and the stack trace pointed to a code snippet, which uses ostringstream
> for data conversion. (int -> string, float -> string, double-> string).
> After changing the ostringstream conversion to sprintf, the crash in the
> application no more occured and the valgrind log was clear as well. It
> seems the problem is in the str() function of ostringstream.
> Consider the following test program in order to reproduce the bug:
>
> #include
> #include
> #include
> #include
> #include
>
> int main()
> {
>
> std::vector v;
> {
> std::ostringstream sstr;
> sstr << (double)1.12;
> v.push_back(sstr.str());
> }
>
> return 1;
> }
>
>
> The problem occured with gcc 3.4.2 and 3.4.4 compilers with -O2
> optimization. Test program had been running both on 32 and 64 bit
> architecture.
> With O1 and O0 no problems was logged by valgrind. 3.2 and 4.0 compilers
> the program was bug-free as well.
> $ g++ -g -O2 -D__STL_DEBUG -DDEBUG test.c
>
> valgrind tool signs the following problems:
> ==5443== Conditional jump or move depends on uninitialised value(s)
> ==5443==at 0x11CD3445: std::string::string(std::string const&) (in
> /usr/lib64/libstdc++.so.6.0.7)
> ==5443==by 0x401907: std::vector std::allocator
> >::_M_insert_aux(__gnu_cxx::__normal_iterator std::vector > >, std::string
> const&) (new:92)
> ==5443==by 0x40152E: main (stl_vector.h:330)
> ==5443==
> ==5443== Conditional jump or move depends on uninitialised value(s)
> ==5443==at 0x401585: main (basic_string.h:215)
> ==5443==
> ==5443== Conditional jump or move depends on uninitialised value(s)
> ==5443==at 0x401427: main (basic_string.h:215)
> ==5443==
> ==5443== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 10 from 5)
> ==5443== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==5443== malloc/free: 3 allocs, 3 frees, 574 bytes allocated.
> ==5443== For counts of detected errors, rerun with: -v
> ==5443== No malloc'd blocks -- no leaks are possible.
>
> Do you have any idea for this issue?
>
> Thanks and regards,
> Laszlo Jordan
>
probably a library version mismatch, libstdc++.so.6.0.7 belongs to GCC
4.1.0.
regards,
lajos
Re: FW: ostringstream: problems with str() function
On Thu, Aug 24, 2006 at 04:36:22PM +0200, Jordan, Laszlo (GE Healthcare) wrote: > > I had a crash in our software, which occured randomly. The valgrind logs > > and the stack trace pointed to a code snippet, which uses ostringstream > > for data conversion > > The problem occured with gcc 3.4.2 and 3.4.4 compilers with -O2 > > optimization... > > valgrind tool signs the following problems: > > ==5443== Conditional jump or move depends on uninitialised value(s) > > ==5443==at 0x11CD3445: std::string::string(std::string const&) (in > > /usr/lib64/libstdc++.so.6.0.7) On Thu, Aug 24, 2006 at 09:48:10PM +0200, FÖLDY Lajos wrote: > probably a library version mismatch, libstdc++.so.6.0.7 belongs to GCC > 4.1.0. Good catch. I guess that resolves the issue (and explains why others have failed to duplicate it).
gcc-4.0-20060824 is now available
Snapshot gcc-4.0-20060824 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060824/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch revision 116385 You'll find: gcc-4.0-20060824.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20060824.tar.bz2 C front end and core compiler gcc-ada-4.0-20060824.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20060824.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20060824.tar.bz2 C++ front end and runtime gcc-java-4.0-20060824.tar.bz2 Java front end and runtime gcc-objc-4.0-20060824.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20060824.tar.bz2The GCC testsuite Diffs from 4.0-20060817 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
gcc -Os option
gcc try.c -o try would give me linking problem /tmp/ccQOkXtu.o: In function `serial_echo_print': try.c:(.text+0x31e): undefined reference to `__inb' try.c:(.text+0x34a): undefined reference to `__outb' try.c:(.text+0x360): undefined reference to `__inb' try.c:(.text+0x387): undefined reference to `__outb' collect2: ld returned 1 exit status but gcc -Os try.c -o try would be OK /w no error what's this -Os option? I thought it's only for optimization. >From upper error it seems as if missing library. I wouldn't make the connection between them. -- View this message in context: http://www.nabble.com/gcc--Os-option-tf2161879.html#a5974772 Sent from the gcc - Dev forum at Nabble.com.
Re: gcc -Os option
wizard00 <[EMAIL PROTECTED]> writes: > gcc try.c -o try would give me linking problem > > /tmp/ccQOkXtu.o: In function `serial_echo_print': > try.c:(.text+0x31e): undefined reference to `__inb' > try.c:(.text+0x34a): undefined reference to `__outb' > try.c:(.text+0x360): undefined reference to `__inb' > try.c:(.text+0x387): undefined reference to `__outb' > collect2: ld returned 1 exit status > > but gcc -Os try.c -o try would be OK /w no error > > what's this -Os option? I thought it's only for optimization. > from upper error it seems as if missing library. I wouldn't make the > connection between > them. This message is appropriate for [EMAIL PROTECTED], not for [EMAIL PROTECTED] Please direct any followups to gcc-help (only). Thanks. Most likely the functions are defined in a header file. When using -Os they are inlined. When not using optimization they are not inlined, and must be found in some library. Ian
Re: REG_OK_STRICT and EXTRA_CONSTRAINT
If the general replacement of REG_OK_STRICT is indeed reload_in_progress || reload_completed, then the substitution *should* of course be in principle be correct (as in: subject to testing. ;) Sure. After I'm done with the base_reg_class changes, I will try modifying address_operand to be something along the lines of your U constraint: return strict ? strict_memory_address_p (Pmode, x) : memory_address_p (Pmode, x), which I'm of course hoping to write as return reload_in_progress || reload_completed ? strict_memory_address_p (Pmode, x) : memory_address_p (Pmode, x), This will also affect the 'p' constraint, and in the end address your "FIXME: This is arguably a bug in gcc." Of course, again, this is subject to testing. Thanks to Zack for discussing this on IRC and hypothesizing that this may be a real bug in GCC. Paolo
Re: FW: ostringstream: problems with str() function
>
> Hi,
>
> I had a crash in our software, which occured randomly. The valgrind logs
> and the stack trace pointed to a code snippet, which uses ostringstream
> for data conversion. (int -> string, float -> string, double-> string).
> After changing the ostringstream conversion to sprintf, the crash in the
> application no more occured and the valgrind log was clear as well. It
> seems the problem is in the str() function of ostringstream.
> Consider the following test program in order to reproduce the bug:
>
> #include
> #include
> #include
> #include
> #include
>
> int main()
> {
>
> std::vector v;
> {
> std::ostringstream sstr;
> sstr << (double)1.12;
> v.push_back(sstr.str());
> }
>
> return 1;
> }
>
>
> The problem occured with gcc 3.4.2 and 3.4.4 compilers with -O2
> optimization. Test program had been running both on 32 and 64 bit
> architecture.
> With O1 and O0 no problems was logged by valgrind. 3.2 and 4.0 compilers
> the program was bug-free as well.
> $ g++ -g -O2 -D__STL_DEBUG -DDEBUG test.c
>
> valgrind tool signs the following problems:
> ==5443== Conditional jump or move depends on uninitialised value(s)
> ==5443==at 0x11CD3445: std::string::string(std::string const&) (in
> /usr/lib64/libstdc++.so.6.0.7)
> ==5443==by 0x401907: std::vector std::allocator
> >::_M_insert_aux(__gnu_cxx::__normal_iterator std::vector > >, std::string
> const&) (new:92)
> ==5443==by 0x40152E: main (stl_vector.h:330)
> ==5443==
> ==5443== Conditional jump or move depends on uninitialised value(s)
> ==5443==at 0x401585: main (basic_string.h:215)
> ==5443==
> ==5443== Conditional jump or move depends on uninitialised value(s)
> ==5443==at 0x401427: main (basic_string.h:215)
> ==5443==
> ==5443== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 10 from 5)
> ==5443== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==5443== malloc/free: 3 allocs, 3 frees, 574 bytes allocated.
> ==5443== For counts of detected errors, rerun with: -v
> ==5443== No malloc'd blocks -- no leaks are possible.
>
> Do you have any idea for this issue?
>
> Thanks and regards,
> Laszlo Jordan
>
probably a library version mismatch, libstdc++.so.6.0.7 belongs to GCC
4.1.0.
regards,
lajos
Re: FW: ostringstream: problems with str() function
fl wrote: probably a library version mismatch, libstdc++.so.6.0.7 belongs to GCC 4.1.0. regards, lajos Aren't libstdc++.so.6.0.n supposed to be compatible with each other (regardless of the value of n)? Michael
