[Bug c/34096] Random number generates the same set of numbers
--- Comment #3 from wilson at specifix dot com 2007-11-15 01:41 --- Subject: Re: Random number generates the same set of numbers rsanghavi at gmail dot com wrote: > --- Comment #2 from rsanghavi at gmail dot com 2007-11-14 22:32 --- > But, even if you seed it, the result is the same unless you seed it with a > random number. I use (time(0) + random number) as seed in my code. Try reading the documentation. On a unix box, you can do "man random" to get docs, which will tell you that it works this way by design. > I am unaware and so asking you, if you have any idea of the project name > random > function belongs to? It is part of the C library. Where the C library comes from depends on the OS, which wasn't specified. They will tell you the same thing we just told you though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34096
[Bug rtl-optimization/33796] valgrind error with -O2 for linux kernel code
--- Comment #5 from wilson at specifix dot com 2007-10-17 20:53 --- Subject: Re: valgrind error with -O2 for linux kernel code bergner at gcc dot gnu dot org wrote: > --- Comment #2 from bergner at gcc dot gnu dot org 2007-10-17 04:46 > --- > Although valgrind is correct that we are doing an uninitialized read, the code > is actually working as designed and is correct. A comment in the code mentioning that the uninit reads are intentional would be useful. Otherwise, you will keep getting this same question, and have to keep answering it. Also, it might be a good idea to make sure that the sparse field is marked as volatile, to ensure that reads are never optimized away. As the gcc optimizer gets better, e.g. LTO and aggressive inlining, it might be possible to end up with a case where gcc can prove that it has an uninit read of this field and optimize it away. This will result in a use of an uninit register. On IA-64, an uninit register may have the NaT (Not a Thing) bit set which is used for speculation. Hence use of an uninit register may cause an unexpected speculation failure, which will cause a program to crash. We can avoid this chain of events by making this a volatile field, which will make it impossible for gcc to optimize away reads from this field, even if uninitialized. It also serves as a clue to other people reading the code that this field is special. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33796
[Bug tree-optimization/33655] [4.3 Regression] ICE in bitfield_overlaps_p, at tree-sra.c:2901
--- Comment #6 from wilson at specifix dot com 2007-10-08 22:16 --- Subject: Re: [4.3 Regression] ICE in bitfield_overlaps_p, at tree-sra.c:2901 hjl at lucon dot org wrote: > This patch doesn't work on Linux/ia64. I got IA-64 is using a TImode bitsizetype because it defines MAX_FIXED_MODE_SIZE to enable TImode. The x86_64 port does not, so it ends up with a DImode bitsizetype and hence does not have the same problem. It looks like a few other 64-bit ports will fail the same way though, like powerpc64 and s390. We can fix this with small patch to add another bitsizetype conversion call. I'll attach a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33655
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
--- Comment #22 from wilson at specifix dot com 2007-09-12 23:35 ---
Subject: Re: [4.3 Regression] Revision 128239
causes libgomp failure
jakub at gcc dot gnu dot org wrote:
> No matter whether it is right or wrong in tree-ssa-operands.c, I think
> sdse should just avoid removing VAR_DECL DECL_HARD_REGISTER store elimination.
This isn't a volatile register, nor a global register variable, so there
should be no problem performing dead store elimination on it. I think
tree-ssa-operands.c needs to be fixed.
I'm not a tree-ssa expert, but the fix needed in tree-ssa-operands.c
seems simple enough. The append_vuse function does two things, it keeps
a list of v_uses, and it keeps a list of loads. We don't want a v_use
if we already have a v_def, but we still need to mark it as a load. We
can do that with a little rearrangement of the code. Like this.
This works for the testcase, but has had no other testing as yet.
2007-09-12 James E. Wilson <[EMAIL PROTECTED]>
* tree-ssa-operands.c (append_vuse): If ann->in_vdef_list true,
then set build_loads before returning.
Index: tree-ssa-operands.c
===
--- tree-ssa-operands.c (revision 128394)
+++ tree-ssa-operands.c (working copy)
@@ -1164,8 +1164,15 @@
/* Don't allow duplicate entries. */
ann = get_var_ann (var);
- if (ann->in_vuse_list || ann->in_vdef_list)
+ if (ann->in_vuse_list)
return;
+ else if (ann->in_vdef_list)
+ {
+ /* We don't want a vuse if we already have a vdef, but we must
+still put this in build_loads. */
+ bitmap_set_bit (build_loads, DECL_UID (var));
+ return;
+ }
ann->in_vuse_list = true;
sym = var;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
--- Comment #21 from wilson at specifix dot com 2007-09-12 19:30 --- Subject: Re: [4.3 Regression] Revision 128239 causes libgomp failure The failure occurs in the sdse (simple dead store elimination) pass. It looks like it is confused by an extended asm statement with input/output operands. It thinks these operands are not read by the asm. If the only use of a variable is inside such an asm, then sdse will think that the variable is never read, and optimize away stores to it. I haven't tried debugging sdse yet to see exactly what is going wrong. Jim -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug target/32552] [4.3 Regression] Runtime failure in SPEC CPU2000 benchmark fma3d and applu
--- Comment #14 from wilson at specifix dot com 2007-09-11 22:32 --- Subject: Re: [4.3 Regression] Runtime failure in SPEC CPU2000 benchmark fma3d and applu On Wed, 2007-09-05 at 09:44 +, jakub at gcc dot gnu dot org wrote: > I have bootstrapped/regtested the > http://gcc.gnu.org/bugzilla/attachment.cgi?id=13831&action=view > patch on ia64-linux, fixed the > FAIL: g++.dg/tree-ssa/pr28003.C execution test > failure, no regressions. I'm certainly happy with the patch I wrote, I just never got around to testing it. Since you have tested it, it is OK to install. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32552
[Bug target/32552] [4.3 Regression] Runtime failure in SPEC CPU2000 benchmark fma3d and applu
--- Comment #13 from wilson at specifix dot com 2007-09-11 22:31 --- Subject: Re: [4.3 Regression] Runtime failure in SPEC CPU2000 benchmark fma3d and applu On Mon, 2007-08-27 at 12:05 +, jakub at gcc dot gnu dot org wrote: > So, what can be done to speed up acceptance of this? I need more time for FSF gcc work, and fewer problems that interfere with my FSF work, but unfortunately that isn't something you can fix. My latest problem, both my laptop and my internet connection failed on the same weekend, making it rather difficult to get any work done. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32552
[Bug target/32552] Runtime failure in SPEC CPU2000 benchmark fma3d and applu
--- Comment #6 from wilson at specifix dot com 2007-07-02 20:30 --- Subject: Re: Runtime failure in SPEC CPU2000 benchmark fma3d and applu On Mon, 2007-07-02 at 19:12 +, zadeck at naturalbridge dot com wrote: > Lets see if an arm person is willing to talk about this. I looked a bit more at the ARM case. dwarf2out_frame_finish has a #ifndef TARGET_UNWIND_INFO check, so the result is that DWARF2 unwind info never gets emitted even though DWARF2_UNWIND_INFO is defined. ARM is using the DWARF2 frame info for the debugger though. For consistency, I'd suggested undefining DWARF2_UNWIND_INFO and defining DWARF2_FRAME_INFO in the arm/bpabi.h file, which better reflects what is actually happening here. But that is just a minor consistency issue. The ARM port will work fine with the suggested changes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32552
[Bug target/32552] Runtime failure in SPEC CPU2000 benchmark fma3d and applu
--- Comment #4 from wilson at specifix dot com 2007-07-02 18:34 --- Subject: Re: Runtime failure in SPEC CPU2000 benchmark fma3d and applu On Sat, 2007-06-30 at 02:10 +, zadeck at naturalbridge dot com > and then define ARCH_DOES_NOT_USE_DWARF2 in the right place in the ia-64. We do use DWARF2 debug info, just not DWARF2 unwind info. So this name is a little misleading. However, this does sound like a good idea. There is already a macro TARGET_UNWIND_INFO that we should be able to use for this. This is defined for targets that have their own non-DWARF2 unwind info format. This is defined by only 2 targets: IA-64 and ARM BPABI. The change you suggested would be safe for IA-64. I don't know about ARM BPABI. I know ARM BPABI has its own unwind info format, but don't know any details. The ARM case is strange. It is setting both DWARF2_UNWIND_INFO and TARGET_UNWIND_INFO. This seems broken to me, as it means we may emit two different kinds of unwind info. This conflicts with the original IA-64 usage of this macro, which wants only the one non-DWARF2 unwind info. However, this means that disabling the defaults.h code for DWARF2_UNWIND_INFO will have no effect for arm as it already sets DWARF2_UNWIND_INFO, so this should be OK. I will have to build an ARM target and check to see what is really happening here. I looked a bit more at what happens if DWARF2_UNWIND_INFO is defined to 0. There are a number of targets that already do this, and the docs say that this disables use of dwarf2 unwind info, but enables use of dwarf frame info for the debugger. But the dwarf2 frame info is redundant for IA-64 because we already have frame info in the IA-64 unwind info, and the debugger already knows how to use this frame info. Unfortunately, the docs say that defining TARGET_UNWIND_INFO is supposed to generate dwarf2 frame info for the debugger. So this will not work for IA-64 as currently documented. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32552
[Bug target/27883] [4.0/4.1/4.2 regression] in schedule_insns, at sched-rgn.c:3038 on mips
--- Comment #11 from wilson at specifix dot com 2006-08-23 21:25 --- Subject: Re: [4.0/4.1/4.2 regression] in schedule_insns, at sched-rgn.c:3038 on mips tbm at gcc dot gnu dot org wrote: > Any update on this, Jim? No. My life continues to be busy and complicated, making it difficult to do much gcc work. However, I did put a patch in the PR. If anyone else has time, they could try testing it. It needs a bootstrap and regression test. I think the problem is best fixed on mainline by merging in the dataflow branch, but for currently supported releases, and for the pending 4.2 release, I think the simple fix in the PR is best. So if we add this fix to the mainline now, then we need to remember to remove it when the dataflow branch goes in, or else prevent it from migrating to the dataflow branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27883
[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent
--- Comment #10 from wilson at specifix dot com 2006-08-22 01:37 --- Subject: Re: New: __builtin_nan() and __builtin_unordered() inconsistent iano at apple dot com wrote: > Cloning due to closed minded bug screener: > ^^^ > >ATTN: PINKSI -- read comments attached at bottom < > ^^^ I tried looking at this, but I don't see any clear bugs here. The fact that NaN compares fail with -funsafe-math-optimizations is curious, but Andrew has already pointed out that this is PR 19116. According to the PR, this seems to be a misfeature of the x86 port. It would help if you were a bit more precise what what bug you are reporting. If you provide a large collection of results, and then claim that they are somehow wrong, without saying what exactly is wrong, then we have to guess what bug you are reporting. Sometimes we guess wrong, and answer the wrong the question. If you give a better bug report, you will get a better answer. The only place where you were clear about a problem is where you claimed that it is inconsistent for -ffinite-math-only to return zero for isnan and 1 for unordered. That however is not a clear bug. -ffinite-math-only says that it assumes that there are no NaNs in the input, and you violated that assumption, so the results you will get are undefined. That is, gcc is allowed to give you any answer here. One can argue that the documentation could be improved to indicate this. One could perhaps also argue that this feature is poorly designed. One can't argue that this is an obvious bug. Similarly for -mno-ieee. With this option, isnan and unordered can return any result for a NaN, as this invokes undefined behaviour. Now, I can see that you have a problem. You want the optimizations afforded by options like -ffinite-math-only, but you still want to be able to test for NaNs in data from untrustworthy sources. That makes sense. Unfortunately, this is a feature that we currently don't support, but one which would be reasonable to add. Hence I think this is really more a feature request than a bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28796
[Bug bootstrap/28577] make of gcc-4.1.1 failed using icc v9.1.042 on ia64
--- Comment #2 from wilson at specifix dot com 2006-08-04 01:34 ---
Subject: Re: make of gcc-4.1.1 failed using icc v9.1.042
on ia64
pinskia at gcc dot gnu dot org wrote:
> --- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-02 20:13
> ---
> If not, then what is the line 49 of the file /usr/include/sys/ucontext.h?
Essentially, we are using offsetof to size an array. This would be a
GCC extension that icc apparently does not support.
Here is an out of context copy of the relevant lines
#if defined __cplusplus && __GNUC_PREREQ (3, 5)
# define _SC_GR0_OFFSET \
__builtin_offsetof (struct sigcontext, sc_gr[0])
#elif defined __GNUC__
# define _SC_GR0_OFFSET \
(((char *) &((struct sigcontext *) 0)->sc_gr[0]) - (char *) 0)
#else
# define _SC_GR0_OFFSET 0xc8/* pray that this is correct... */
#endif
typedef struct ucontext
{
union
{
mcontext_t _mc;
struct
{
unsigned long _pad[_SC_GR0_OFFSET/8];
struct ucontext *_link; /* this should overlay sc_gr[0] */
}
_uc;
}
_u;
}
ucontext_t;
Since current gcc uses __builtin_offsetof for both C and C++, this
header file could perhaps be changed to use that, assuming of course
that icc accepts this new extension, which maybe it does not.
This file is from glibc. If anything needs to be changed here, it is
glibc, not gcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28577
[Bug target/27767] Problem: gcc 4.0.3 on Unix_SV
--- Comment #5 from wilson at specifix dot com 2006-06-09 00:17 ---
Subject: Re: Problem: gcc 4.0.3 on Unix_SV
mirko dot bruzzone at primeur dot com wrote:
> gt-c-pragma.h:46: parse error before `__attribute__'
gt-c-pragma.h uses attribute unused in a parameter list, before the
parameter type. Like so:
void sub (__attribute__ ((unused)) int i) { }
This is a syntax that gcc-2.7.2 doesn't support. It was added later.
You could try hacking this out, but it might be simpler to try baby
steps. Use 2.7.2 to compile gcc-2.95.3, use 2.95.3 to compile
gcc-3.3.4, use 3.3.4 to compile gcc-4.x.
I see that 2.95.3 supports this syntax, so it might be able to compile
gcc-4.x, but there may also be other problems, so going from 2.95.e to a
3.x release, and then to a 4.x release is more likely to work.
We could probably fix this with some ifdefs, but gcc-2.7.2 is so old
that it doesn't seem worth the hassle. Plus there are probably other
issues that haven't been noticed yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27767
[Bug middle-end/24998] [4.2 Regression] Build failure: undefined symbol __floatunsitf
--- Comment #27 from wilson at specifix dot com 2006-03-09 22:21 --- Subject: Re: [4.2 Regression] Build failure: undefined symbol __floatunsitf fxcoudert at gcc dot gnu dot org wrote: > Adding the maintainers of all those in Cc list. I don't know what > US_SOFTWARE_GOFAST, but from the last sentence quoted above, it looks like I > don't really want to know :) I'll tell you anyways. See http://www.smxinfo.com/ussw/gofast.htm Our support code hasn't been updated in such a long time that I'm skeptical it works with current versions of the gofast library. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug target/25272] gcc fails to compile for target h8300-hitachi-hms with unrecognizable insn
--- Comment #3 from wilson at specifix dot com 2005-12-06 05:15 --- Subject: Re: gcc fails to compile for target h8300-hitachi-hms with unrecognizable insn pinskia at gcc dot gnu dot org wrote: > --- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-06 04:32 > --- > This might be a 64bit HOST_WIDE_INT bug in the h8300 back-end. Yes, it is. I do builds with CC="gcc -m32". I also build binutils this way. I doubt it will work correctly if compiled as 64-bit code. I haven't cared enough yet to try to fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25272
[Bug debug/25234] [2.95.2/3.3.3/4.0.0 Regression] g++ fails to emit debug information for SOME local variables in class member function that has templated local variables
--- Comment #7 from wilson at specifix dot com 2005-12-06 03:03 --- Subject: Re: New: [2.95.2/3.3.3/4.0.0 Regression] g++ fails to emit debug information for SOME local variables in class member function that has templated local variables schaudhu at blackrock dot com wrote: > When trying to debug the following block of code, some of the function's local > variables can not be displayed using display, print, or info scope > [function]. > Display and print will work after a certain point within the stack frame of > the > function foo(), but long after the variables are initialized. Please examine > the following source code and output. Part of the problem here is understanding what "scope" means. The gdb command "info scope foo" will only print variables in the outer-most function scope for foo, i.e. variables whose scope starts at the beginning of the function. In your testcase, mfact is defined part-way into the function. Older gcc versions probably lie, and say that mfact has the same scope as foo. Newer gcc versions try to emit accurate scope info, creating a lexical block to represent where mfact is live, even though there is no lexical block in the input. So with gcc-4.x, info scope foo does not report mfact, and this is correct, because mfact is defined in a subscope. If you try something like "info scope test.cc:37" then you will get all symbols you are expecting to see, as they are all live at this point. So there is no gcc problem here, though one could perhaps argue that the gdb info scope command output is confusing and needs to be improved. With gcc-3.3, things are a bit more confused. The scope info changes depending on whether -DGOODDGB is defined, which seems wrong. With it defined, rcode/n/mfacts all have function wide scope. Without it defined, only mfacts has function scope. The others, rcode/n/nfacts are all defined in a subscope. I didn't look at why this happens. This does appear to be a bug. Oh, by the way, your g++ -DGOODDBG example is wrong. You claim that a symbol is missing, but that symbol is excluded when -DGOODDBG is defined, so there is no problem there. I tried gcc-3.4, and the scope info looks OK, i.e. roughly the same as gcc-4.0. Based on the info you have provided, and the fact that we are no longer maintaining gcc-3.3, I don't see anything here to fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25234
[Bug bootstrap/24710] gfortran - fails to build on Mac OSX -10.4.3
--- Comment #17 from wilson at specifix dot com 2005-11-09 02:06 ---
Subject: Re: New: gfortran - fails to build on Mac OSX
-10.4.3
dir at lanl dot gov wrote:
> strip -o libgcc_s.10.4.dylib_T${mlib} \
> -s ../.././gcc/config/rs6000/darwin-libgcc.10.4.ver -c -u \
> libgcc_s${mlib}.1.dylib || exit 1 ; \
> Could Not Open (-o) To Read
This looks like it could be a problem with the strip program thinking
that -o is a filename instead of an option. The strip call here was
only added a month ago. You wouldn't have seen this before if your last
update was over a month ago.
Do you maybe have a strip on your path before /usr/bin/strip?
Are you using alternative tools that have their own version of strip
that is broken?
Are you using the most recent cctools release, that came out on Oct 31?
It is available in the infrastructure directory on the gcc.gnu.org ftp
server.
Just using grep, I can't find that error message anywhere in /usr/lib/*
or in /usr/bin/strip on my machine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #5 from wilson at specifix dot com 2005-11-09 00:34 ---
Subject: Re: Shared libgcc not used for linking by default
sje at cup dot hp dot com wrote:
> --- Comment #3 from sje at cup dot hp dot com 2005-11-08 21:22 ---
> I am not convinced that this is a bug.
There is an obvious bug. Have you actually looked at the specs in
question? They have %{shared-libgcc ... %{static-libgcc ...}} which
can't possibly be right.
However, there is no bug in FSF gcc. I suspect a bug in the gcc sources
being distributed from the HP web site. I haven't checked that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug bootstrap/24438] ARM cross compile build fails with assembler errors in crtstuff.c
--- Comment #3 from wilson at specifix dot com 2005-10-19 19:48 --- Subject: Re: New: ARM cross compile build fails with assembler errors in crtstuff.c newell at cei dot net wrote: > Configured with: ../gcc-4.1-20050515/configure --target=arm-elf > --prefix=/home/newell/xgcc --with-gnu-as --with-gnu-ld --with-newlib --verbose > --enable-threads --enable-languages=c Also, this works much better if you use the exact same --prefix for gcc and binutils. If you want gcc installed in /home/newell/xgcc, then you should install binutils there too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24438
[Bug target/24232] [4.1 Regression] ICE: segmentation fault in sched-ebb.c:220 add_missing_bbs
--- Comment #10 from wilson at specifix dot com 2005-10-11 06:26 --- Created an attachment (id=9960) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9960&action=view) trivial hack to make the reduced testcase work Actually, come to think of it, other targets don't use schedule_ebbs unless the -fsched2-use-superblocks option is used, which is probably why others haven't run into this problem. I haven't checked to see if schedule_ebbs has other ways of preventing jump_insns from scheduling across each other. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24232
[Bug target/24232] [4.1 Regression] ICE: segmentation fault in sched-ebb.c:220 add_missing_bbs
--- Comment #9 from wilson at specifix dot com 2005-10-11 06:20 --- Or maybe I will look at it later tonight. The problem seems to be that we have no code that will make a jump insn dependent on the previous jump insn when we are scheduling a region that contains multiple basic blocks. For a target with a single condition code register things will just work out OK, but for IA-64, with multiple predicate registers and conditional execution, we can end up with pairs of branches that aren't dependent on each other, which means that they can be scheduled across each other, which is bad. With a trivial hack to force a dependency for branches, I no longer get an ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24232
[Bug middle-end/21105] [4.0/4.1 Regression] Compiling of large array fails
--- Additional Comments From wilson at specifix dot com 2005-08-16 00:47 --- Subject: Re: [4.0/4.1 Regression] Compiling of large array fails pinskia at gcc dot gnu dot org wrote: > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-25 > 15:50 --- > Hmm, Jim posted a patch here: > <http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00377.html> but > never applied it. I never finished my patch. I was hoping someone else would help finish it. Since it is my patch, I'll follow up on this. The first thing I did here is grep the entire tree for TREE_OVERFLOW (TYPE_SIZE (...)) since all such occurances are broken. I found 3. One in the C front end (this bug), one in the C++ front end, and one in the Ada front end. I can't create a testcase for the Ada bug, nor can I at the moment build the Ada front end, so there is not much I can do there other than maybe create a new bug report for it and insert the obvious patch. The C++ code is identical to the C code, so the same testcase and patch work here. Unfortunately, there is a problem. I get tmp.cc:13: error: size of array array is too large tmp.cc:17: error: array was not declared in this scope The first error is correct, the second one isn't. Or at least I assume it isn't. I'm not qualified to comment on that, nor am I qualified to fix it. So, um, I guess I am creating yet another new bug report for that. For the C front end, I have a patch that I believe is correct, and I have a small testcase that I think is reasonably portable. I need to drop my testcase into the testsuite with dg annotations, and test it all with a bootstrap and make check. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21105
[Bug middle-end/15855] [3.4/4.0/4.1 Regression] g++ crash with -O2 and -O3 on input file
--- Additional Comments From wilson at specifix dot com 2005-08-12 19:07 --- Subject: Re: [3.4/4.0/4.1 Regression] g++ crash with -O2 and -O3 on input file phython at gcc dot gnu dot org wrote: > --- Additional Comments From phython at gcc dot gnu dot org 2005-08-12 > 06:21 --- > On ia64-linux postreload-gcse does exactly nothing and takes 35% of the > compile > time at -O1 -fgcse-after-reload. I didn't finish a build at -O2. What testcase and compiler version are you using for this? I tried taking a look, but wasn't able to reproduce any problem. I was able to compile both testcases in the PR at -O2 in about 20 secs and about 200MB. Both testcases in the PR have issues. The first one generates lots of errors from the C++ front end, and doesn't actually end up doing much compiling. The second one wants a non-existent expat.h file and is thus uncompilable without changes. If I delete the include of the missing expat.h file, then again I get C++ front end errors and little compilation. I tried various gcc versions, 4.0.x, mainline, 3.3.x, but I got the same result from all of them. Maybe you have a copy of the missing expat.h file? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15855
[Bug debug/21828] [4.0/4.1 Regression] debug info omitted for uninitialized variables
--- Additional Comments From wilson at specifix dot com 2005-07-08 00:46 --- Subject: Re: [4.0/4.1 Regression] debug info omitted for uninitialized variables hjl at lucon dot org wrote: > --- Additional Comments From hjl at lucon dot org 2005-07-05 16:56 > --- > Patches for mainline and 4.0 are posted at > http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00270.html > I hope they lead to the proper fixes and this critical regression > is fixed in 4.0.1. I think you are just compounding the mistake created by Mark Mitchell's patch for PR 18556. I mentioned this in comment #8, which unfortunately didn't get sent to the gcc-bugs mailing list. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21828
[Bug tree-optimization/21568] [4.0/4.1 regression] Casts in folding *& omitted
--- Additional Comments From wilson at specifix dot com 2005-07-08 00:41 --- Subject: Re: [4.0/4.1 regression] Casts in folding *& omitted gcc2eran at tromer dot org wrote: > And here is what N1124 [6.3.2.1/1] says: > "When an object is said to have a particular type, the type is >specified by the lvalue used to designate the object." > See my point? In the C99 standard, 6.5.4 Cast Operators, Footnote 85 "A cast does not yield an lvalue. Thus, a cast to a qualified type has the same effect as a cast to the unqualified version of the type." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21568
[Bug rtl-optimization/17808] Scheduler overly conservative in sched-deps
--- Additional Comments From wilson at specifix dot com 2005-07-08 00:08 --- Subject: Re: Scheduler overly conservative in sched-deps steven at gcc dot gnu dot org wrote: > /tmp/ccBDW5xy.s:186: Warning: Additional NOP may be necessary to workaround > Itanium processor A/B step errata^M These can be ignored. The Itanium1 pre-release errata support has already been removed from current binutils and gcc sources. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17808
