A question about your patch for PR c++/26534
Hi Mark,
I have a question about your patch for PR c++/26534. In particular,
you added to standard_conversion in call.c the following code:
if (expr)
{
tree bitfield_type;
bitfield_type = is_bitfield_expr_with_lowered_type (expr);
if (bitfield_type)
from = bitfield_type;
}
Now consider the following testcase derived from PR c++/27505 and my
analysis on why it fails.
struct s {
bool field:8;
};
void
foo (struct s *p)
{
if (!p->field)
;
}
When build_unary_op builds TRUTH_NOT_EXPR, it calls
perform_implicit_conversion to convert p->field to the boolean type.
(FWIW, p->field is expressed as
>). The call to perform_implicit_conversion eventually
gets to standard_conversion. The code fragment of standard_conversion
shown above changes FROM to the boolean_type. Since TO is also the
boolean type, no conversion happens, causing
perform_implicit_conversion to return the original expression, which
is of INTEGER_TYPE.
invert_truthvalue, called from cp/typeck.c:3969, expects nothing but
expressions of BOOLEAN_TYPE, so it ICEs at fold-const.c:3165.
Now, is the code in standard_conversion meant to be an optimization or
something that's required for language conformance? If the latter is
the case, can we somehow force a conversion?
Thanks,
Kazu Hirata
Re: www pages outdated
On Wed, May 10, 2006 at 08:49:48PM -0700, HeroreV wrote: > The pages at http://www.gnu.org/software/gcc/ are > several months old, even though the page at > http://gcc.gnu.org/about.html says: I forwarded this mail to [EMAIL PROTECTED] Janis
intl directory: gcc vs. src
I sent this email earlier to just binutils and got no replies, so I thought I would try broadening my scope: While looking at updating the src tree to use newer versions of autoconf I have run into the issue of the intl directory. I found some old discussions about the two different versions (one in the src tree, one in the gcc tree) but it doesn't look like any work was done to bring them into alignment. By removing the AM_PROG_INSTALL definition from aclocal.m4 I was able to run autoconf 2.59 on the src tree intl subdir with no problems but I was wondering if we should take the time to synchronize the GCC intl directory with the src tree intl directory. The GCC version is already configured with autoconf 2.59. I did some testing by copying my GCC intl directory (plus config.rpath) into my src tree and I was able to build binutils and gas with no problem and with no other changes needed. This was on a system where libintl was not installed and the intl subdir was built. What do people who build in a combined tree do with intl? Do they use the GCC version or the src tree version? Is there any consensus about whether or not there should be a single version of intl, and if so, which one should be used? Steve Ellcey [EMAIL PROTECTED]
gcc-4.0-20060511 is now available
Snapshot gcc-4.0-20060511 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060511/ 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 113715 You'll find: gcc-4.0-20060511.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20060511.tar.bz2 C front end and core compiler gcc-ada-4.0-20060511.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20060511.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20060511.tar.bz2 C++ front end and runtime gcc-java-4.0-20060511.tar.bz2 Java front end and runtime gcc-objc-4.0-20060511.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20060511.tar.bz2The GCC testsuite Diffs from 4.0-20060504 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.
how to make gcc stop when there is a warning
I'm R'ing T' F'ing M' to try figure this out, but perhaps I can find the answer faster just by asking. I'm going through a bunch of C (sometimes Fortran 77) code and changing the type of certain arrays, but of course I need to make absolutely sure that the functions that recieve those arrays are expecting the right types. Funny, but I find, "Warning: passing argument 3 of do_foo() from incompatible pointer type" to be comforting, refreshing, and satisfying. It makes me feel warm and fuzzy inside. Plus it tells me where I need to fix my code to get the calculations right. As such, I'd like to tell gcc to quit when a warning is encountered (or even if a specific warning is encountered). Is there a way to do this? If it helps, I'm using gcc 4.0.2. Attempts at aid, and heartless ridicule, will be most appreciated. Dan -- "Give up learning, and put an end to your troubles." -- Lao Tzu
Re: how to make gcc stop when there is a warning
> As such, I'd like to tell gcc to quit when a warning is encountered > (or even if a specific warning is encountered). Is there a way to do > this? Yes. -Werror. If you can tell us why you weren't able to find it in the documentation, perhaps we can address that! Cheers, Ben
Re: how to make gcc stop when there is a warning
> > I'd like to tell gcc to quit when a warning is encountered > > (or even if a specific warning is encountered). Is there a way to do > > this? > > Yes. -Werror. If you can tell us why you weren't able to find it in > the documentation, perhaps we can address that! Partly, because I never learned to read. Partly, I'm impatient. Partly, because when any search containing "warning" is extremely unhelpful when you actually LIKE the warnings. Partly, the man page says, "Make all warnings into errors" for -Werror when perhaps it should say, "Treat warnings as errors: stop compilation immediately," or something like that. The latter might, however, have something to do with my not being able to read. It's probably my fault, so addressing the issue means sending some dark-suited fellers around and roughing me up a bit. ;) In any case, I appreciate the quick response! Dan -- "Give up learning, and put an end to your troubles." -- Lao Tzu
ada bootstrap broken on powerpc64-linux-gnu
Bootstrapping with ada fails for me on powerpc64-linux-gnu with:
/abuild/aj/gcc/./gcc/xgcc -B/abuild/aj/gcc/./gcc/
-B/opt/gcc/4.2-devel/powerpc64-suse-linux-gnu/bin/
-B/opt/gcc/4.2-devel/powerpc64-suse-linux-gnu/lib/ -isystem
/opt/gcc/4.2-devel/powerpc64-suse-linux-gnu/include -isystem
/opt/gcc/4.2-devel/powerpc64-suse-linux-gnu/sys-include -c -g -O2 -fPIC
-specs=ldblspecs -mno-minimal-toc -W -Wall -gnatpg g-os_lib.adb -o
g-os_lib.o -save-temps -v
Reading specs from /abuild/aj/gcc/./gcc/specs
Reading specs from /abuild/aj/gcc/./gcc/ldblspecs
Target: powerpc64-suse-linux-gnu
Configured with: /cvs/gcc-svn/trunk/configure --prefix=/opt/gcc/4.2-devel
--enable-checking=yes,rtl --enable-threads=posix --enable-clocale=gnu
--enable-__cxa_atexit --enable-shared
--enable-languages=c,c++,ada,treelang,java,fortran,objc --with-system-zlib
--with-cpu=default32 powerpc64-suse-linux-gnu
Thread model: posix
gcc version 4.2.0 20060511 (experimental)
/abuild/aj/gcc/./gcc/gnat1 -quiet -dumpbase g-os_lib.adb -O2 -W -Wall -fPIC -g
-mno-minimal-toc -gnatpg -gnatO g-os_lib.o g-os_lib.adb -o g-os_lib.s
+===GNAT BUG DETECTED==+
| 4.2.0 20060511 (experimental) (powerpc64-suse-linux-gnu) GCC error: |
| in change_address_1, at emit-rtl.c:1784 |
| Error detected at g-os_lib.adb:2603:1|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report. |
| Include the exact gcc or gnatmake command that you entered. |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files). |
+==+
Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:380
A debugging session shows:
(gdb) r
Starting program: /abuild/aj/gcc/gcc/gnat1 -quiet -dumpbase g-os_lib.adb -O2 -W
-Wall -fPIC -g -mno-minimal-toc -gnatpg -gnatO g-os_lib.o g-os_lib.adb -o
g-os_lib.s
Breakpoint 3 at 0x10ac8190
Breakpoint 4 at 0x10ac7e70
Breakpoint 3 at 0xfec4908
Breakpoint 4 at 0xfec3148
Breakpoint 1, fancy_abort (file=
0x10b397b0 "/cvs/gcc-svn/trunk/gcc/emit-rtl.c", line=1784, function=0x10b3949c
"change_address_1") at /cvs/gcc-svn/trunk/gcc/diagnostic.c:642
642 internal_error ("in %s, at %s:%d", function, trim_filename (file),
line);
(gdb) bt
#0 fancy_abort (file=0x10b397b0 "/cvs/gcc-svn/trunk/gcc/emit-rtl.c",
line=1784, function=0x10b3949c "change_address_1")
at /cvs/gcc-svn/trunk/gcc/diagnostic.c:642
#1 0x103fa248 in change_address_1 (memref=0xf7970700, mode=BLKmode,
addr=0xf7a9ff20, validate=)
at /cvs/gcc-svn/trunk/gcc/emit-rtl.c:1784
#2 0x1040c4c4 in use_anchored_address (x=0xf7970700) at
/cvs/gcc-svn/trunk/gcc/explow.c:592
#3 0x1042a0dc in expand_expr_real_1 (exp=, target=, tmode=, modifier=EXPAND_CONST_ADDRESS,
alt_rtl=0x0) at /cvs/gcc-svn/trunk/gcc/expr.c:6831
#4 0x88004282 in ?? ()
#5 0x10431578 in expand_expr_real (exp=0xf7f55070, target=0x0, tmode=SImode,
modifier=EXPAND_CONST_ADDRESS, alt_rtl=0x0)
at /cvs/gcc-svn/trunk/gcc/expr.c:6638
#6 0x1043a1f4 in expand_expr_addr_expr_1 (exp=0x10b397b0, target=0x0,
tmode=SImode, modifier=EXPAND_NORMAL) at /cvs/gcc-svn/trunk/gcc/expr.h:494
#7 0x10427728 in expand_expr_real_1 (exp=, target=0x0,
tmode=, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at /cvs/gcc-svn/trunk/gcc/expr.c:6525
#8 0x88004282 in ?? ()
#9 0x10431578 in expand_expr_real (exp=0xf7f81600, target=0x0, tmode=VOIDmode,
modifier=EXPAND_NORMAL, alt_rtl=0x0) at /cvs/gcc-svn/trunk/gcc/expr.c:6638
#10 0x10402290 in output_ttype (type=0xf7f81600, tt_format=155,
tt_format_size=4) at /cvs/gcc-svn/trunk/gcc/expr.h:500
#11 0x10407a20 in output_function_exception_table () at
/cvs/gcc-svn/trunk/gcc/except.c:3787
#12 0x4282 in ?? ()
#13 0x104463b0 in rest_of_handle_final () at /cvs/gcc-svn/trunk/gcc/final.c:3929
#14 0x107e13b0 in execute_one_pass (pass=0x10c8253c) at
/cvs/gcc-svn/trunk/gcc/passes.c:864
#15 0x107e15b8 in execute_pass_list (pass=0x10c8253c) at
/cvs/gcc-svn/trunk/gcc/passes.c:911
#16 0x107e15d0 in execute_pass_list (pass=0x10c830c8) at
/cvs/gcc-svn/trunk/gcc/passes.c:912
#17 0x107e15d0 in execute_pass_list (pass=0x10c83094) at
/cvs/gcc-svn/trunk/gcc/passes.c:912
#18 0x102da6dc in tree_rest_of_compilation (fndecl=0xf7f04b00) at
/cvs/gcc-svn/trunk/gcc/tree-optimize.c:418
#19 0x1001d8a4 in gnat_expand_body (gnu_decl=0x10b397b0) at
/cvs/gcc-svn/trunk/gcc/ada/misc.c:653
#20 0x10855298 in cgraph_expand_fun
Re: ada bootstrap broken on powerpc64-linux-gnu
On May 11, 2006, at 9:38 PM, Andreas Jaeger wrote: Bootstrapping with ada fails for me on powerpc64-linux-gnu with: http://gcc.gnu.org/bugzilla//show_bug.cgi?id=27536 -- Pinski
Re: intl directory: gcc vs. src
Steve Ellcey <[EMAIL PROTECTED]> writes: > By removing the AM_PROG_INSTALL definition from aclocal.m4 I was able to > run autoconf 2.59 on the src tree intl subdir with no problems but I was > wondering if we should take the time to synchronize the GCC intl > directory with the src tree intl directory. The GCC version is already > configured with autoconf 2.59. > > I did some testing by copying my GCC intl directory (plus config.rpath) > into my src tree and I was able to build binutils and gas with no > problem and with no other changes needed. This was on a system where > libintl was not installed and the intl subdir was built. > > What do people who build in a combined tree do with intl? Do they use > the GCC version or the src tree version? Is there any consensus about > whether or not there should be a single version of intl, and if so, > which one should be used? Yes, there should be a single version of intl. I don't think anybody cares which version is used, as long as it works. If you have taken the time to test a unified intl, and are prepared to fix any problems, I think your patch would be great. Ian
