I would like that svn print the URL of each file in the diff output,
like CVS's `RCS file'. One of the scripts I use to test GCC (which I
have not contributed yet because of the svn transition) used it to
detect the directory in which the patch should apply.
Danny, can you do it for 1.3? If
Paolo Bonzini wrote:
I would like that svn print the URL of each file in the diff output, like
CVS's
`RCS file'. One of the scripts I use to test GCC (which I have not contributed
yet because of the svn transition) used it to detect the directory in which
the patch should apply.
Is it
On Tue, Nov 08, 2005 at 04:05:20PM +0100, Christian Joensson wrote:
Currently, on the gomp branch, I get this:
if /bin/sh ./libtool --mode=compile
/usr/local/src/branch/objdir.gomp/./gcc/xgcc
-B/usr/local/src/branch/objdir.gomp/./gcc/
-B/usr/local/sparc64-unknown-linux-gnu/bin/
On Tue, Nov 08, 2005 at 05:00:43PM +0100, Christian Joensson wrote:
Sure, here's the (relevant(?) part of) generated libgomp_f.h:
static inline void
omp_check_defines (void)
{
char test[(24 != sizeof (omp_lock_t)
|| 4 != __alignof (omp_lock_t)
|| 24 != sizeof
On Tue, Nov 08, 2005 at 09:17:10AM -0700, Mark Cuss wrote:
Hi Eric
sparc-sun-solaris2.9-objdump -f returns the following:
libc.so:
start address 0x
...
Congratulations, this must be the longest top-post ever.
--
Markus
- Original Message -
From: Markus Trippelsdorf [EMAIL PROTECTED]
To: Mark Cuss [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; gcc@gcc.gnu.org
Sent: Tuesday, November 08, 2005 9:29 AM
Subject: Re: Skipping incompatable libaries on a SPARC cross compile
On Tue, Nov 08, 2005 at 09:17:10AM
On 11/8/05, Christian Joensson [EMAIL PROTECTED] wrote:
On 11/8/05, Jakub Jelinek [EMAIL PROTECTED] wrote:
On Tue, Nov 08, 2005 at 05:00:43PM +0100, Christian Joensson wrote:
Sure, here's the (relevant(?) part of) generated libgomp_f.h:
static inline void
omp_check_defines (void)
On 11/7/05, Daniel Jacobowitz [EMAIL PROTECTED] wrote:
[snip]
I have generated an SVK repository to go with this. As anyone who's
doing or done this themselves can attest, it takes a long time and a
lot of RAM and a whole ton of I/O.
Yes, it takes very long time, few hours before I
On Tue, Nov 08, 2005 at 10:37:13AM -0800, Devang Patel wrote:
On 11/7/05, Daniel Jacobowitz [EMAIL PROTECTED] wrote:
[snip]
I have generated an SVK repository to go with this. As anyone who's
doing or done this themselves can attest, it takes a long time and a
lot of RAM and a whole
On Tue, 2005-11-08 at 13:42 -0500, Daniel Jacobowitz wrote:
On Tue, Nov 08, 2005 at 10:37:13AM -0800, Devang Patel wrote:
On 11/7/05, Daniel Jacobowitz [EMAIL PROTECTED] wrote:
[snip]
I have generated an SVK repository to go with this. As anyone who's
doing or done this
On Tue, Nov 08, 2005 at 01:47:52PM -0500, Daniel Berlin wrote:
If you try to commit to the mirror, it will try to commit to the
underlying repo.
That's how svk push actually works.
Yes, of course, but what if you've checked out using a read-only
protocol? Is it going to fall down? Refuse
On Tue, 2005-11-08 at 13:56 -0500, Daniel Jacobowitz wrote:
On Tue, Nov 08, 2005 at 01:47:52PM -0500, Daniel Berlin wrote:
If you try to commit to the mirror, it will try to commit to the
underlying repo.
That's how svk push actually works.
Yes, of course, but what if you've checked
As mentioned before, there is a brace missing after the gcc_s_hpux64.
This brace is needed to close off the shared-libgcc rule before the
static-libgcc rule starts. You then must delete a brace from the end of
the !static rule which has one too many.
Yes, doing so gives the correct
Hello!
gcc-4.1.20051105
-fno-stack-protector-all is not recognised/implemented
apps built w/ -fstack-protector-all segfault
test env:
- uClibc-svn
- guard is set up like glibc does in ld.so as non-TLS version
- libssp is not used, gcc's configure check was enabled to recognize
Snapshot gcc-3.4-20051108 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20051108/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Steve Ellcey wrote:
I am not convinced there is a bug here.
There is an extremely obvious bug here. Please look at the specs that
Albert Chin included in his email message. There is no way that
-static-libgcc should require -shared-libgcc, which is what happens in
his specs.
The only
On Wed, 2005-11-02 at 18:02 -0800, Mark Mitchell wrote:
Jeffrey A Law wrote:
For example, if the only use was inside an unreachable hunk of
code, does that count as a use or not?
Yes, the EDG front-end does this:
[EMAIL PROTECTED]:~/tmp$ cat test.cpp
void f() {
int i;
if (0)
On Tue, Nov 08, 2005 at 04:00:42PM -0800, Jim Wilson wrote:
The only part I don't understand is where these specs came from, as
this doesn't match anything in the FSF tree. I'm guessing that HP
is distributing a modified gcc with patches added to it, and these
patches are buggy. I went to
On Tue, 2005-11-08 at 17:22, Albert Chin wrote:
A .depot file is a tar file so just untar it.
Yeah, I knew that, it just took me a while to remember. I added
comments to PR 24718 explaining what the underlying problem is, and
confirming the bug. I probably can't do much more as I don't have an
I've put a possible patch in the metabug (24639). As I mention in
the comments, I'm not comfortable self-approving it given my lack of
knowledge about the option processing code and the debate over what
we want the default -Wuninitialized behavior to be.
jeff
If it helps, I withdraw my
Hi All,
I'm wondering if the following behavior is:
1. An already reported bug.
2. Not reported, I need to file a bugzilla.
3. Disputed.
Here's the test case:
typedef unsigned short ushort;
namespace X
{
typedef unsigned short ushort;
}
using namespace X;
int main()
{
ushort us
On 11/8/05, Daniel Berlin [EMAIL PROTECTED] wrote:
It will simply tell you you don't have access :)
However, it is rejecting local branch creation also.
---
$ svk ls /svkgcc/gcc/local_branches
Path /gcc/local_branches is not a versioned directory
bardoli:~ bardoli$ svk mkdir
On Tue, Nov 08, 2005 at 06:41:05PM -0800, Devang Patel wrote:
On 11/8/05, Daniel Berlin [EMAIL PROTECTED] wrote:
It will simply tell you you don't have access :)
However, it is rejecting local branch creation also.
---
$ svk ls /svkgcc/gcc/local_branches
Path /gcc/local_branches is
On 11/8/05, Daniel Jacobowitz [EMAIL PROTECTED] wrote:
Isn't this, creating local branches, is a local operation ?
//gcc is a mirrored location. You have to create your branches outside
of there; try /svkgcc/local-gcc in your example.
Yes, this works.
Thanks,
-
Devang
Howard Hinnant [EMAIL PROTECTED] writes:
| Hi All,
|
| I'm wondering if the following behavior is:
|
| 1. An already reported bug.
| 2. Not reported, I need to file a bugzilla.
| 3. Disputed.
|
| Here's the test case:
|
| typedef unsigned short ushort;
|
| namespace X
| {
| typedef
On 11/8/05, Jakub Jelinek [EMAIL PROTECTED] wrote:
On Tue, Nov 08, 2005 at 05:00:43PM +0100, Christian Joensson wrote:
Sure, here's the (relevant(?) part of) generated libgomp_f.h:
static inline void
omp_check_defines (void)
{
char test[(24 != sizeof (omp_lock_t)
|| 4
I have been noticing the following error in trunk and in branch.
It looks look in libstdc++-v3 signbit,
Has it been reported yet?
/home/sherlock/gcc/o/gcc/xgcc -B/home/sherlock/gcc/o/gcc/
-B/usr/local/i686-pc-c
ygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem
/usr/local/i686-pc-cygwin/i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rui Wang wrote:
Hi all,
To transform my java RMI code to windows native code, I followed Ranjit
Mathew's tutorial to compile gcc to a cross compiler.
http://ranjitmathew.hostingzero.com/phartz/gcj/bldgcj.html
[...]
After successfully
Bobby McNulty wrote:
I have been noticing the following error in trunk and in branch.
I get no such error when compiling the trunk.
/home/sherlock/gcc/o/gcc/xgcc -B/home/sherlock/gcc/o/gcc/
-B/usr/local/i686-pc-c
ygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem
Brian Dessent wrote:
Bobby McNulty wrote:
I have been noticing the following error in trunk and in branch.
I get no such error when compiling the trunk.
/home/sherlock/gcc/o/gcc/xgcc -B/home/sherlock/gcc/o/gcc/
-B/usr/local/i686-pc-c
ygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/
--- Comment #7 from uros at kss-loka dot si 2005-11-08 08:12 ---
Fixed on mainline and 4.0 branch.
--
uros at kss-loka dot si changed:
What|Removed |Added
--- Comment #15 from bonzini at gcc dot gnu dot org 2005-11-08 08:19
---
now fixed on 4.0 branch too
--
bonzini at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from jason at gcc dot gnu dot org 2005-11-08 08:32 ---
Subject: Bug 21123
Author: jason
Date: Tue Nov 8 08:32:26 2005
New Revision: 106634
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106634
Log:
PR c++/21123
* cp/method.c (use_thunk): Use
--- Comment #9 from uros at kss-loka dot si 2005-11-08 10:04 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00498.html
--
uros at kss-loka dot si changed:
What|Removed |Added
--- Comment #14 from thebohemian at gmx dot net 2005-11-08 10:15 ---
But we don't need to use ffi_call here, we can just call the exception
throwing function directly.
Right. That worked fine.
Then you'll realize that these functions don't need to be separate at all.
Yep. I made
--- Comment #10 from ahu at ds9a dot nl 2005-11-08 10:15 ---
An easy solution might be to check for __gthread_active_p() in
bits/basic_string before calling __exchange_and_add, and to do this locally and
non-atomically otherwise.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24704
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-11-08 10:16 ---
Note that it is too late for the inliner to come in at builtin expansion time.
It may be possible to fix this with the SSA inliner on IPA branch, but I'm
not sure if it is worth it. Maybe Honza can give some
--- Comment #11 from pcarlini at suse dot de 2005-11-08 10:53 ---
(In reply to comment #10)
An easy solution might be to check for __gthread_active_p() in
bits/basic_string before calling __exchange_and_add, and to do this locally
and
non-atomically otherwise.
Yes, this solution
--- Comment #10 from pcarlini at suse dot de 2005-11-08 10:58 ---
Ok, apparently short-term at least, smart solutions using libgcc and dynamic
linking will not be implemented (one blocker are systems using a static
libgcc.a).
Therefore this one becomes a pure libstdc++-v3 PR. Then what
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-11-08 11:08
---
(In reply to comment #2)
In function `*_gfortrani_set_fpu':.\
/fpu-target.h:42: warning: warning: fedisableexcept is not implemented and
will
always fail^M
You're seeing this warning only for the in-pack
--- Comment #12 from pcarlini at suse dot de 2005-11-08 11:30 ---
In my opinion, the way to go is consistently using the macro __GTHREADS which
is undefined when --enable-threads=single is passed. This is consistent with
the approach already used in mt_allocator, for instance. And
--- Comment #13 from bert dot hubert at netherlabs dot nl 2005-11-08 11:43
---
Subject: Re: __gnu_cxx::__exchange_and_add is called even for single threaded
applications
On Tue, Nov 08, 2005 at 11:30:46AM -, pcarlini at suse dot de wrote:
--- Comment #12 from pcarlini at
--- Comment #14 from pcarlini at suse dot de 2005-11-08 11:50 ---
(In reply to comment #13)
Indeed, other parts of libstdc++ already rely on __gthread_active_p().
Sure, see mt_alloc: there is an external __GTHREADS and an internal
__gthread_active_p().
Using __GTHREADS would get
--- Comment #15 from bert dot hubert at netherlabs dot nl 2005-11-08 11:58
---
Subject: Re: __gnu_cxx::__exchange_and_add is called even for single threaded
applications
On Tue, Nov 08, 2005 at 11:50:24AM -, pcarlini at suse dot de wrote:
Of course does the right thing, there is
--- Comment #16 from pcarlini at suse dot de 2005-11-08 12:06 ---
(In reply to comment #15)
How about we make (or I contribute) a set of 'atomic-if-needed'
'exchange-and-add' and 'add' inlineable functions?
These could just replace __gnu_cxx::__exchange_and_add in all places and
--- Comment #3 from maslowski73 at wp dot pl 2005-11-08 12:09 ---
GCC version 3.3.6 and 3.3.2 have this bug either.
The dependency files appear in the current directory.
But, if the preprocessing fails the dependency file (although empty) remains in
the right place.
How to repeat:
+++ This bug was initially created as a clone of Bug #215 +++
When compiling and generating dependencies (using -MD or
-MMD): and using option -o with a relative or absolute path
for the resulting object file, the rule generated should
reflect the correct location of the .o file
Instead, the
--- Comment #7 from jakub at gcc dot gnu dot org 2005-11-08 12:18 ---
Why are you so sure it is not a GCC bug?
It clearly is a C++ frontend bug:
grep -C1 _ZN5TemplImE2_tE __thread.s __threadmain.s
__thread.s- movq-16(%rbp), %rax
__thread.s: movq%rax,
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #7 from uros at kss-loka dot si 2005-11-08 12:40 ---
Created an attachment (id=10173)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10173action=view)
Patch to fix the ice
This patch fixes the failure for me, but...
--
--- Comment #8 from simon dot marshall at misys dot com 2005-11-08 12:51
---
FYI, I raised this error with glibc with a slightly different attachment.
http://sourceware.org/bugzilla/show_bug.cgi?id=1830 has the code Jakub refers
to.
--
--- Comment #19 from pinskia at gcc dot gnu dot org 2005-11-08 12:52
---
(In reply to comment #18)
Bootstrap of gcc-4.1-20051105 succeeded for c,c++,objc,obj-c++.
Testsuite still in progress.
This is good enough to close this as fixed. Thanks.
--
pinskia at gcc dot gnu dot org
--- Comment #8 from uros at kss-loka dot si 2005-11-08 12:53 ---
This patch fixes the failure for me, but...
... we actually gain nothing here.
From .loop2_done, we have following sequence, where mem-reg load is pushed out
of the loop:
(insn 21 16 39 0 (set (reg:DF 64)
--- Comment #26 from pinskia at gcc dot gnu dot org 2005-11-08 12:54
---
Fixed at least on the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from green at redhat dot com 2005-11-08 12:54 ---
(In reply to comment #14)
Then you'll realize that you don't need to bother setting up
the ffi_cif - all you need is the exception argument.
I doubt that this is right. The ffi_prep_closure() needs to know which
--- Comment #6 from amodra at bigpond dot net dot au 2005-11-08 12:58
---
Looks like combine is not updating reg life info.
(gdb) set var dump_file=stderr
(gdb) n
(gdb)
Register 137 died unexpectedly.
(gdb)
;; basic block 6, loop depth 0, count 0
;; prev block 5, next block 7
;;
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-08 13:02 ---
*** Bug 13668 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-08 13:02 ---
*** This bug has been marked as a duplicate of 19450 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #9 from uros at kss-loka dot si 2005-11-08 13:23 ---
Bah... set_unique_reg_note is needed:
/* If new move insn is invalid (i.e. move of const_double to
387 stack register), force constant into memory. */
if (recog_memoized (inv-insn) == -1)
{
rtx src =
--- Comment #11 from pcarlini at suse dot de 2005-11-08 13:37 ---
Changing the declarations in include/bits/atomicity.h to inline definitions
forwarding to the builtins and including bits/atomic_word.h instead of
bits/atomicity.h in config/cpu/*/atomicity.h for the supported arch
--- Comment #10 from steven at gcc dot gnu dot org 2005-11-08 13:45 ---
The patch from comment #7 is wrong.
The proper fix is already on the killloop-branch. You could try my patch for
PR 24408, which should depend on this one.
--
steven at gcc dot gnu dot org changed:
--- Comment #10 from dir at lanl dot gov 2005-11-08 14:18 ---
The make bootstrap ends with -
make bootstrap
...
...
checking for .preinit_array/.init_array/.fini_array support... no
checking if mkdir takes one argument... no
Using `../.././gcc/config/rs6000/rs6000.c' for
--- Comment #17 from bert dot hubert at netherlabs dot nl 2005-11-08 14:26
---
Subject: Re: __gnu_cxx::__exchange_and_add is called even for single threaded
applications
On Tue, Nov 08, 2005 at 12:06:02PM -, pcarlini at suse dot de wrote:
To repeat: this is needed anyway,
--- Comment #18 from pcarlini at suse dot de 2005-11-08 14:34 ---
(In reply to comment #17)
To repeat: this is needed anyway, because we want to use consistently the
--thread-model configure option. Nothing will go in not checking also and
exploting the macro. Then comes
--- Comment #19 from pcarlini at suse dot de 2005-11-08 14:54 ---
(In reply to comment #18)
Sure, this is the general idea. I'm a little bit concerned that for something
apparently so elemental as an addiction (atomic, yes...) we are going to add
a conditional, but probably, given
--- Comment #11 from dir at lanl dot gov 2005-11-08 15:15 ---
Down loading gfortran using svn took 40 percent longer and gave the same
results on the build -
By the way the GNU Fortran Page -
http://gcc.gnu.org/fortran/
still says to use anonymous CVS
The following program doesn't work correctly when compiled with -fopenmp:
==
#includecstdio
templateint void foo()
{
#pragma omp parallel
{
printf(ALL\n);
#pragma omp master
printf(MASTER\n);
}
}
int main()
{
foo0();
return
The following program doesn't work correctly when compiled with -fopenmp:
==
#includecstdio
#includeomp.h
#includeunistd.h
templateint void foo()
{
#pragma omp parallel
{
if (omp_get_thread_num()==0) sleep(1);
printf(ONE\n);
#pragma omp
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #5 from schnetter at aei dot mpg dot de 2005-11-08 15:54
---
I would like to identify the cause of this problem. Would it help if I tracked
down the patch number that caused this problem? Andrew, do you have an
automated system to do that, or is someone already doing it?
--- Comment #4 from bergner at vnet dot ibm dot com 2005-11-08 16:04
---
Shouldn't libtool being using -print-multi-os-directory rather than
-print-search-dirs?
http://www.redhat.com/archives/fedora-devel-list/2004-January/msg01027.html
--
bergner at vnet dot ibm dot com changed:
--- Comment #5 from schwab at suse dot de 2005-11-08 16:16 ---
How do you find out where to splice the multi-os directory into the libraray
path?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20425
This entry is being opened as a result of discussion on the mailing list. It
was discovered in 4.1.0 mainline. The root cause has existed for a very long
time but the change that exposed it was commited in February 2005.
This problem is almost certainly existant on cygwin builds, but this has
--- Comment #1 from tj at laurenzo dot org 2005-11-08 16:21 ---
Created an attachment (id=10174)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10174action=view)
Patch to correct the problem for non ELF targets
This patch has been applied to mainline and will be applied to the 4.0
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-08 16:22 ---
I think there is a dup of this bug already.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24736
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-08 16:25 ---
*** This bug has been marked as a duplicate of 20993 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-08 16:25 ---
*** Bug 24736 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-08 16:26 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-08 16:27 ---
Fixed by:
+2005-11-08 Terry Laurenzo [EMAIL PROTECTED]
+
+ PR java/24736
+ * gjavah.c (HANDLE_CODE_ATTRIBUTE): Only define for ELF Object
+ formats.
+ * gjavah.c (decompile_method): Add
--- Comment #9 from dberlin at gcc dot gnu dot org 2005-11-08 16:34 ---
Subject: Bug 23382
Author: dberlin
Date: Tue Nov 8 16:34:48 2005
New Revision: 106643
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106643
Log:
2005-11-08 Daniel Berlin [EMAIL PROTECTED]
Fix PR
--- Comment #10 from dberlin at gcc dot gnu dot org 2005-11-08 16:36
---
Fixed
--
dberlin at gcc dot gnu dot org changed:
What|Removed |Added
When using gcc 4.0.0 or 4.0.1 on MacOS, the following code fails when
optimizations (-O1 - -O3) is turned on:
--- snip ---
bool TestFoo(const bool trueBool) {
CFoo foo;
// bool falseBool = trueBool ? false: true;// This works!
bool falseBool = !trueBool;
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-08 16:40
---
How did you configure gcc? From the looks of it, you are doing some thing
wrong.
By the way the GNU Fortran Page -
http://gcc.gnu.org/fortran/
still says to use anonymous CVS
Yes that is a different bug and
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-08 16:43 ---
I Think this has already been fixed in 4.0.2 by the patch for PR 23326.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-08 16:44 ---
Actually on second thought, this is a dup of bug 23326.
*** This bug has been marked as a duplicate of 23326 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-08 16:44
---
*** Bug 24737 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from fredrik dot littmarck at propellerheads dot se
2005-11-08 16:45 ---
Created an attachment (id=10175)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10175action=view)
Test Case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24737
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-08 16:46 ---
Note also you are using Apple's compiler and should report this to them.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24737
--- Comment #7 from law at redhat dot com 2005-11-08 17:03 ---
The SSA optimizers clean this testcase enough to no longer emit a bogus
uninitialized warning. It is (of course) possible to create more complex tests
which would still generate bogus uninitialized warnings.
--
law at
--
law at redhat dot com changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5035
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-08 17:13 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from law at redhat dot com 2005-11-08 17:18 ---
No plans exist to address these issues in the 3.x series. It works as expected
in GCC 4.1.
--
law at redhat dot com changed:
What|Removed |Added
--- Comment #5 from law at redhat dot com 2005-11-08 17:23 ---
Bogus warning no longer issued with GCC 4.1 based compilers.
--
law at redhat dot com changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-08 17:25 ---
(In reply to comment #5)
Bogus warning no longer issued with GCC 4.1 based compilers.
Huh:
gcc version 4.1.0 20051106 (experimental)
../t6.c: In function foo:
../t6.c:13: warning: j is used uninitialized in
--- Comment #4 from simon dot marshall at misys dot com 2005-11-08 17:41
---
Is there a target milestone for this? IWBI it were fixed on 3.4 as well as
4.0.
(Appologies if I seem impertinent, I'm not too familiar with the way things
work.)
--
--- Comment #6 from bonzini at gcc dot gnu dot org 2005-11-08 17:47 ---
For now, I am trying to get the size of umf_analyze down by removing the
unnecessary prototypes, beautifying the code, etc...
Paolo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
--- Comment #4 from law at redhat dot com 2005-11-08 17:47 ---
Just an interesting tidbit.
This testcase exposes a much more difficult/interesting long term problem.
Namely, how should we handle uninitialized warnings for variables which are
exposed by optimization.
ie, in this case
In i386.h, there are
{ push-args,-MASK_NO_PUSH_ARGS, \
N_(Use push instructions to save outgoing arguments) }, \
{ no-push-args, MASK_NO_PUSH_ARGS,\
N_(Do not use push instructions to
1 - 100 of 191 matches
Mail list logo
