Re: Redundant limit check for switch
Why can't this information be used to optimize comparisons? My patch caused GCC to infer that x & 7 > 7 is false. But I couldn't think of a quick way to use this to optimize away the check, because then GCC crashed. Does it work only for consecutive ands? Or is it just an early constant folding: return (x + 1) & (0x0f & 0x0c & 0x3ff & 0xff); ? In this case, it is. Paolo
Need help to fill bug report (gcc 4.0.1 and above)
Hello, I have currently a reproducable seg fault from an exe produced by gcc 4.0.1 (*). It does not appear using gcc 2.95, 3.2, 3.3, 3.4. If I run it throught gdb I get: 0x402814b1 in __gnu_cxx::__pool::_M_reclaim_block () from /usr/lib/libstdc++.so.6 (gdb) bt #0 0x402814b1 in __gnu_cxx::__pool::_M_reclaim_block () from /usr/lib/libstdc++.so.6 #1 0x08062907 in __gnu_cxx::__mt_allocstd::string> >, __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::deallocate (this=0x806d888, __p=0x8221f10, __n=1) at mt_allocator.h:746 ... and the structure being: static std::set< std::pair< std::string, std::string > > foo; If I try to run through valgrind 3.0 everything is fine, and it produce correct output. Any advice on a way to narrow down a simple testcase, right now it would require building VTK(**) Thanks for any help, Mathieu (*) debian testing. but I can also reproduce with gcc 4.1.0 20050726 (gcc-snapshot) (**) http://vtk.org
Question about pre_edge_insert () in gcse.c
Hello, While reading the function pre_edge_insert () in gcse.c, something didn't make sense to me: According to the documentation: /* Where PRE_INSERT_MAP is nonzero, we add the expression on that edge if it reaches any of the deleted expressions. */ I understand that before inserting an expression on an edge we should check if it reaches a deleted anticipatable occurrence. This also make sense, since we don't want to insert expression on edge if none of the anticipatable occurrences it reaches was deleted for some reason (e.g. all of these occurrences are inside a PARALLEL instructions). But, when we find a deleted anticipatable occurrence we do: /* Insert this expression on this edge if it would reach the deleted occurrence in BB. */ if (!TEST_BIT (inserted[e], j)) This test prevents us from inserting the same expression twice on the same edge, but it doesn't check that this deleted occurrence is actually reached from the current edge. If what I'm saying here is correct, some redundant expression might be inserted. It also seem to me that the "inserted" sbitmap is unnecessary. We could just use "continue" after an insertion instead of using TEST_BIT (inserted[e], j) and SET_BIT (inserted[e], j). Thanks, Leehod.
Re: Question about pre_edge_insert () in gcse.c
> If what I'm saying here is correct, some redundant expression might > be inserted. We have testcases (search bugzilla for GCSE) with redundant expressions being inserted by GCSE (repeatedly, such that if you run GCSE 5 times, it inserts the same expression 5 times in the same place). If you are correct, some of these should be fixed by changing that. --Dan
Re: Problem building 3.3.6 (with 3.4.4): xgcc: cannot specify -o with -c or -S and multiple compilations
Andrew Walrond wrote: Can anybody explain what this error might mean? /tmp/gcc-3-3.heretix/work/gcc/xgcc "" -B/tmp/gcc-3-3.heretix/work/gcc/ ^^^ -c ../../../../gcc-3.3.6/libstdc++-v3/libsupc++/guard.cc -fPIC -DPIC -o guard.o ^^ gcc sees those as two input files (two non-option arguments). I suspect somewhere along the line you have something like CFLAGS='""' by mistake, or somehow the string "" is being passed into CFLAGS. Chekc your environment and whatever args you gave to `make bootstrap' Kean
Re: 206 GCC HEAD regressions, 196 new, with your patch on 2005-08-23T19:50:19Z.
On Fri, Aug 26, 2005 at 05:03:08PM +0100, Joern RENNECKE wrote:
> java uses char_type_node for its character type, which is 16 bits.
> gcc/java/decl.c:747 java_init_decl_processing:
> TYPE_PRECISION (char_type_node) = 16;
>
> On the other hand, tree.c uses char_type_node as the type of the
> smallest addressable
> unit:
>
> tree.c:489 make_node_stat
>case tcc_type:
> TYPE_UID (t) = next_type_uid++;
> TYPE_ALIGN (t) = char_type_node ? TYPE_ALIGN (char_type_node) : 0;
Indeed, fixing this avoids the need for your followup workaround.
Tested on i686-linux, which previously saw the problem as timeouts
on all libjava tests.
r~
* stor-layout.c (finalize_type_size): Revert workaround from 08-26.
* tree.c (make_node_stat): Use BITS_PER_UNIT instead of alignment
of char_type_node.
Index: stor-layout.c
===
RCS file: /cvs/gcc/gcc/gcc/stor-layout.c,v
retrieving revision 1.240
diff -u -p -d -r1.240 stor-layout.c
--- stor-layout.c 26 Aug 2005 17:17:05 - 1.240
+++ stor-layout.c 28 Aug 2005 16:26:38 -
@@ -1399,23 +1399,23 @@ finalize_type_size (tree type)
/* Normally, use the alignment corresponding to the mode chosen.
However, where strict alignment is not required, avoid
over-aligning structures, since most compilers do not do this
- alignment. Also, we must avoid overriding a larger alignment
- requirement coming from a user alignment of one of the fields. */
- /* ??? The non-aggregate code is also needed to reduce the alignment
- of java types with alignment less than 16 bits. The problem stems
- from java/decl.c using char_type_node for the 16 bit character type,
- while tree.c:make_node uses it as the type of the smallest addressable
- unit to initialize the alignment of all types. */
- unsigned mode_align = GET_MODE_ALIGNMENT (TYPE_MODE (type));
+ alignment. */
if (TYPE_MODE (type) != BLKmode && TYPE_MODE (type) != VOIDmode
- && ((STRICT_ALIGNMENT && mode_align >= TYPE_ALIGN (type))
+ && (STRICT_ALIGNMENT
|| (TREE_CODE (type) != RECORD_TYPE && TREE_CODE (type) != UNION_TYPE
&& TREE_CODE (type) != QUAL_UNION_TYPE
&& TREE_CODE (type) != ARRAY_TYPE)))
{
- TYPE_ALIGN (type) = mode_align;
- TYPE_USER_ALIGN (type) = 0;
+ unsigned mode_align = GET_MODE_ALIGNMENT (TYPE_MODE (type));
+
+ /* Don't override a larger alignment requirement coming from a user
+alignment of one of the fields. */
+ if (mode_align >= TYPE_ALIGN (type))
+ {
+ TYPE_ALIGN (type) = mode_align;
+ TYPE_USER_ALIGN (type) = 0;
+ }
}
/* Do machine-dependent extra alignment. */
Index: tree.c
===
RCS file: /cvs/gcc/gcc/gcc/tree.c,v
retrieving revision 1.500
diff -u -p -d -r1.500 tree.c
--- tree.c 16 Aug 2005 00:35:50 - 1.500
+++ tree.c 28 Aug 2005 16:26:39 -
@@ -488,7 +488,7 @@ make_node_stat (enum tree_code code MEM_
case tcc_type:
TYPE_UID (t) = next_type_uid++;
- TYPE_ALIGN (t) = char_type_node ? TYPE_ALIGN (char_type_node) : 0;
+ TYPE_ALIGN (t) = BITS_PER_UNIT;
TYPE_USER_ALIGN (t) = 0;
TYPE_MAIN_VARIANT (t) = t;
Re: Problem building 3.3.6 (with 3.4.4): xgcc: cannot specify -o with -c or -S and multiple compilations
On Sunday 28 August 2005 16:06, Kean Johnston wrote: > Andrew Walrond wrote: > > Can anybody explain what this error might mean? > > > > /tmp/gcc-3-3.heretix/work/gcc/xgcc "" -B/tmp/gcc-3-3.heretix/work/gcc/ > > ^^^ > > > -c ../../../../gcc-3.3.6/libstdc++-v3/libsupc++/guard.cc -fPIC -DPIC -o > > guard.o > > ^^ > > gcc sees those as two input files (two non-option arguments). > I suspect somewhere along the line you have something like > CFLAGS='""' by mistake, or somehow the string "" is being > passed into CFLAGS. Chekc your environment and whatever > args you gave to `make bootstrap' Its a lot worse than that :( Libtool is *randomly* replacing parts of the commandline with "". Something is very fscked up :( Thanks for the reply though, Andrew
Re: [PATCH]: Proof-of-concept for dynamic format checking
[Sorry for the way-late response... was on vacation] On Fri, Aug 19, 2005 at 02:16:53PM -0700, Ian Lance Taylor wrote: > > The idea of letting gcc load a .so to do the checking also seems fine. > > At least then the checking language is a standard one, not one we made > > up. I think this is a wonderfully good idea. > Yes. My main concerns would be > > * It's obviously vastly more powerful than anything we actually need, > and using dlopen exposes the compiler to bugs in the implementation > of the format checker--slowness, random memory clobbering, etc. I just don't see this as a problem. > * The compiler is, in its own way, a system security component. If > somebody were to put format checking into a system header file which > used a shared library, then substituting that shared library-- > perhaps by just getting the compiler to pick up a different version > of it--becomes an avenue for a complex but subtle attack on the > system as a whole. I see this as a problem. OK, let's solve it. The solution has two parts: - Allow arbitrary shared libraries to be specified on the command line. BFD can then build one before it compiles, and pass it as an argument to GCC. - Define a trusted directory to allow shared libraries to be loaded by the installed system compiler, via #pragma. I think this has a lot more mileage in it than spending months debating how to represent the format specifiers in source code. Of course, we'll need to create a C interface for doing this, which will take some time to do right. But we know how to do that! -- Daniel Jacobowitz CodeSourcery, LLC
Re: memset() Optimization on x86-32 bit
Kevin McBride <[EMAIL PROTECTED]> writes: > If you look closely, you can see that %edi can be automatically loaded > directly without problems, and that (%eax) can be directly loaded into > (%esp). Is this behavior intentional (for bugs I don't know about in > earlier processors) or could this optimization be fixed to use less > instructions? >From the code you presented, I expect this optimization can be fixed. But it's difficult to work with an incomplete program fragment. Please open a PR at http://gcc.gnu.org/bugzilla/ with the complete preprocessed source code for a file showing the problem. Thanks. Ian
Re: [PATCH]: Proof-of-concept for dynamic format checking
Maybe I should avoid making suggestions that would make the project
more complex, especially since I'm not implementing it, but...
If we can describe the argument types expected for a given format
string, then we can produce warnings for values used but not yet set
(%s with an uninitialized automatic char array, but not %n with an
uninitialized int), and let the compiler know what values are set by
the call for use in later warnings. For additions like bfd's %A and %
B, though, we'd need a way of indicating what fields of the pointed-
to structure are read and/or written, because some of them may be
ignored, or only conditionally used.
Seems to me the best way to describe that is either calling out to
user-supplied C code, or providing something very much like a C
function or function fragment to show the compiler how the parameters
are used -- off the top of my head, say, map 'A' to a static function
format_asection which takes an asection* argument and reads the name
field, which function can be analyzed for data usage patterns and
whether it handles a null pointer, but which probably would be
discarded by the compiler. Mapping format specifiers to code
fragments might also allow the compiler to transform
bfd_print("%d:%A",sec,num)
to
printf("%d:%s",num,sec->name)
if it had enough information. But that requires expressing not just
the data i/o pattern, but what the formatting actually will be for a
specifier, which sometimes may be too complex to want to express.
Just a thought...
Ken
Successful Build and Installation of GCC
> Output from running srcdir/config.guess. Do not send that file itself, just
the one-line output from running it.
i586-pc-linux-gnu
> The output of gcc -v for your newly installed gcc. This tells us which
version of GCC you built and the options you passed to configure.
Using built-in specs.
Target: i586-pc-linux-gnu
Configured with: ../gcc-4.0.1/configure --program-suffix=4 --with-gnu-as
--with-gnu-ld --enable-version-specific-runtime-libs --with-cpu=k6
Thread model: posix
gcc version 4.0.1
> Whether you enabled all languages or a subset of them. If you used a full
distribution then this information is part of the configure options in the
output of gcc -v, but if you downloaded the âcoreâ compiler plus additional
front ends then it isn't apparent which ones you built unless you tell us
about it.
all ('full distribution' default)
> If the build was for GNU/Linux, also include:
> The distribution name and version (e.g., Red Hat 7.1 or Debian 2.2.3); this
information should be available from /etc/issue.
Welcome to SuSE Linux 9.3 (i586) - Kernel \r (\l)
> The version of the Linux kernel, available from uname --version or uname -a.
Linux xx 2.6.11.4-21.8-default #1 Tue Jul 19 12:42:37 UTC 2005 i586 i586
i386 GNU/Linux
> The version of glibc you used; for RPM-based systems like Red Hat, Mandrake,
and SuSE type rpm -q glibc to get the glibc version, and on systems like
Debian and Progeny use dpkg -l libc6.
glibc-2.3.4-23.4
Notes:
Test results also submitted.
SuSE 9.3 did not include fortran which I need.
APPEAL to steering committee: [Bug target/23605] memset() Optimization on x86-32 bit
Everyone, Please take notice that I am appealing my bug (number 23605) to the steering committee of GCC on the basis that it is a legimate bug/enhancement in need of a through research. I believe that Andrew Pinski is trying to keep the research from occuring by means of marking the bug as invalid. I am hoping that the steering committee will order a through research on the bug. There are times when it might be best to have things like memset() inlined by the compiler itself, as outlined in my latest comment to the bug. - KJM Original Message Subject: [Bug target/23605] memset() Optimization on x86-32 bit Date: 28 Aug 2005 22:21:15 - From: pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] References: <[EMAIL PROTECTED]> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-28 22:21 --- First it is not our bug your distro installs i686 versions, go bug them instead. Second glibc not using SSE is its bug and not ours, report it to them instead. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23605 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter.
Re: APPEAL to steering committee: [Bug target/23605] memset() Optimization on x86-32 bit
On Sun, 2005-08-28 at 18:48 -0400, Kevin McBride wrote: > Everyone, > > Please take notice that I am appealing my bug (number 23605) to the > steering committee of GCC on the basis that it is a legimate > bug/enhancement in need of a through research. The Steering committee really doesn't get involved in bug reports. Your only recourse is public shaming. Sorry.
Re: APPEAL to steering committee: [Bug target/23605] memset() Optimization on x86-32 bit
Kevin McBride <[EMAIL PROTECTED]> writes: > Please take notice that I am appealing my bug (number 23605) to the > steering committee of GCC on the basis that it is a legimate > bug/enhancement in need of a through research. I believe that Andrew > Pinski is trying to keep the research from occuring by means of marking > the bug as invalid. > > I am hoping that the steering committee will order a through research on > the bug. There are times when it might be best to have things like > memset() inlined by the compiler itself, as outlined in my latest > comment to the bug. I'm sure we all look forward to receiving orders from the steering committee. As pinskia noted, later, in the PR, you want the -minline-all-stringops option, which is documented. In the meantime, I think there may be a bug here, in that memset is open coded for the i386 at -O0. That doesn't make sense to me; e.g., it prevents setting a breakpoing on memset. This happens in this conditional in ix86_expand_clrmem: if ((!optimize || optimize_size) && (count == 0 || ((count & 0x03) && (!optimize_size || (count & 0x03) + (count >> 2) > 7 /* do cld; stos */ This conditional dates back to here: Tue Jan 11 16:26:47 MET 2000 Jan Hubicka <[EMAIL PROTECTED]> ... (cld pattern): New. (movstrsi, clrstr, cmpstr, strlen expander): Emit cld instruction (movstrsi_1, clrstrsi_1, cmpstrsi_1, strlensi_1, cmpstrsi_nz_1 insn): Do not output cld instruction Any thoughts on this? Ian
Re: Problem building 3.3.6 (with 3.4.4): xgcc: cannot specify -o with -c or -S and multiple compilations
Libtool ... automatically implies Something is very fscked up I have had no end of bad luck, and very little good luck, with libtool. Not to mention that its use (at least in stock 1.4.3) breaks paradigms like 'make install DESTDIR=blah' But this is gcc list, not a libtool list, so I will just wish you good luck and my condolences go out to you. Debugging libtool can be extremely painful. Kean
Status of --enable-mapped-location
Does anyone know of the status of --enable-mapped-location? I tried to do a bootstrap and test and I got a lot of failures due to getting the wrong line number and file for the error message when dealing with macros. Thanks, Andrew Pinski
unused variable warning
In gcc/g++ version 4.0 there is no way to turn off the unused variable warning enabled by -Wall with a command line switch. I think this is a bug: it should be possible to selectively turn on or off all warnings (on the command line). The advice in the documentation is to attach __attribute__((unused)) to the selected variable. This may be inappropriate for three distinct reasons: (a) It is a GNU extension (b) it clutters the code (c) It isn't always easy to tell if a variable is unused Comment (c) means: C/C++ code is not always hand written. In my case I am generating code that sometimes contains an unused variable as a result of a conservative optimisation failing to detect the variable is not required. I can of course just enable all the warnings selected by -Wall, other than the unused warning .. but this has two problems: (a) it is gcc version specific which warnings can be produced, so it would be necessary to generate and consult configuation data .. this may not be possible in a cross compilation situation (where a process is preparing script to be executed on another machine, for example). (b) it makes a real mess of the build having such long command lines .. (gcc provides lots of warnings :) BTW: gcc/g++ 4.0 is one heck of a better compiler than the 3.x series! Nice work!! [Pls CC me as I don't subscribe to this list] -- John Skaller signature.asc Description: This is a digitally signed message part
Re: APPEAL to steering committee: [Bug target/23605] memset() Optimization on x86-32 bit
On Sun, Aug 28, 2005 at 06:48:17PM -0400, Kevin McBride wrote: > Please take notice that I am appealing my bug (number 23605) to the > steering committee of GCC on the basis that it is a legimate > bug/enhancement in need of a through research. I believe that Andrew > Pinski is trying to keep the research from occuring by means of marking > the bug as invalid. I've looked at the bug in bugzilla; it's not marked as invalid, though I tend to agree with Andrew and Ian's comments in the log. In any case, the SC doesn't get involved in cases like this. And even if the SC lost its sanity and decided to micromanage Bugzilla as you ask, it would take a 3/4 vote, and you certainly wouldn't get mine.
[DEAD] APPEAL to steering committee: [Bug target/23605] memset() Optimization on x86-32 bit
Joe Buck wrote: I've looked at the bug in bugzilla; it's not marked as invalid, though I tend to agree with Andrew and Ian's comments in the log. I set the bug back to unconfirmed after I noticed that, in my opinion, there can be more optimization done. In any case, the SC doesn't get involved in cases like this. And even if the SC lost its sanity and decided to micromanage Bugzilla as you ask, it would take a 3/4 vote, and you certainly wouldn't get mine. I didn't realize that the SC had no control over Bugzilla. Unless there was something I missed, all what the web site said was: > In April 1999 the steering committee was appointed by the FSF as the > official GNU maintainer for GCC and changed its name to GCC steering > committee. All I can now say is: If no one on the GCC team wants to fully investigate my bug, then there's nothing I can do about the bug except to implement the fix in my own code. This appeal started up over misunderstandings between Andrew Pinski, Ian Lance Taylor, and I. I felt that Ian Lance Taylor agreed with me prior to submitting the bug to the bug tracker, and so, felt humiliated by Andrew Pinski's comments. When Ian Lance Taylor stepped in, he made the misunderstanding obvious to me, and so, I did what I could to see if gcc was performing optimizations as much as possible. This appeal is now dead. Let's get on with our projects, regardless if my bug report will ever be turned into a bug fix. - KJM
Re: Status of --enable-mapped-location
Andrew Pinski wrote: Does anyone know of the status of --enable-mapped-location? I tried to do a bootstrap and test and I got a lot of failures due to getting the wrong line number and file for the error message when dealing with macros. I haven't had time to work on gcc for a while, but I'm hoping Ben Ellison (with my advice) will be able to take a look. The biggest group of remaining trouble spots *used* to be when testing pch, since we don't properly save/resore the line number table. I haven't even done a --enable-mapped-location build in quite a while, so I haven't no idea what regressions there might be. I'll at least do a bootstap+check run to get a feel for the status. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
MASK_GNU_AS == MASK_GAS
It appears that the ia64 port introduced the internal define MASK_GNU_AS that is used the same was as the historical MASK_GAS define. There was some discussion of this about 5 years ago as part of a larger discussion about possible user level changes. It would seem to be a pretty simple change to just make them consistent for internal gcc sources without diddling with the user visible issues. -Fred
