--- Comment #12 from jvdelisle at gcc dot gnu dot org 2008-10-18 05:36
---
Ignore comment #11. I got wrong PR number in Changelog. Should have been
37863.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-10-18 05:32
---
Fixed on trunk. I accidentally committed the patch with the wrong PR number in
the Changelog (37707)
This I will backport to 4.3 in a day.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37863
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-10-18 05:28
---
Subject: Bug 37863
Author: jvdelisle
Date: Sat Oct 18 05:27:23 2008
New Revision: 141208
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141208
Log:
Fix ChangeLog
2008-10-17 Jerry DeLisle <[EMAIL
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2008-10-18 05:25
---
Subject: Bug 37707
Author: jvdelisle
Date: Sat Oct 18 05:23:47 2008
New Revision: 141207
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141207
Log:
2008-10-17 Jerry DeLisle <[EMAIL PROTECTED]
--- Comment #2 from flameeyes at gentoo dot org 2008-10-17 22:36 ---
Which gives it even more usefulness to be optionally treated as an error, since
it really helps to avoid shooting oneself in the foot...
I guess it would be bad to have a way to -Wno- it, but it would be nice to at
lea
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-17 22:34 ---
That is because this is a pedantic warning which is enabled by default.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37866
The new -Werror= option for GCC 4.3 is very useful to make GCC error out for
specific warnings, but it currently lacks a way to make that warning an error
(which is very useful to avoid skipping parameters in fprintf()-like functions.
Even -fdiagnostics-show-option suggested by the manual doesn't
--- Comment #6 from suckfish at ihug dot co dot nz 2008-10-17 22:18 ---
Pleasantly, my fears that this was just the tip of the iceburg seems to be
wrong. Writing some test cases, found another bug involving a shift, and also
the ICE below [fixed by some combination of change above and 3
make[3]: Entering directory
`/mnt/devel/lfs/lfs-build/gcc-4.3.2/build-gcc-4.3.2/i686-pc-linux-gnu/libgfortran'
if /bin/sh ./libtool --tag=CC --mode=compile
/mnt/devel/lfs/lfs-build/gcc-4.3.2/build-gcc-4.3.2/./gcc/xgcc
-B/mnt/devel/lfs/lfs-build/gcc-4.3.2/build-gcc-4.3.2/./gcc/
-B/mnt/devel/lfs/lfs-
--- Comment #3 from bernard at brenda-arkle dot me dot uk 2008-10-17 21:08
---
I've seen this with 4.3.1 and 4.3.2 official releases with (as it happens)
athlon-64 again (but 32-bit Linux). But then I also saw it with 4.3.1
on a pure Pentium4 system, so I don't think it's really 64-bit
--- Comment #11 from andreast at gcc dot gnu dot org 2008-10-17 20:59
---
Entered in testing part on sparc-solaris2.10
Bootstrap ok. with patch in comment #10
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37815
--- Comment #18 from jakub at gcc dot gnu dot org 2008-10-17 20:19 ---
Fixed in 4.4.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
We found an interesting bootstrap failure in gcc after changing a machine
definition some, the important bits are below. Something is wrong, but it is
hard to say exactly what. The warning would be fine, if there were no
preprocessor involved. But, it is. The warning doesn't make any sense for
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-10-17 19:32
---
I will try to look at this tonight.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37863
--- Comment #5 from fago at earthlink dot net 2008-10-17 18:06 ---
Just to document: I came across this bug with OpenMP using gcc 4.3.2 on RHEL4,
with static libraries, and found the threads mentioned in #1 and #2.
Linking dynamically fixed the segfaults on RHEL4. It does seem to be a b
--- Comment #23 from amacleod at redhat dot com 2008-10-17 17:37 ---
Subject: Bug 37102
Author: amacleod
Date: Fri Oct 17 17:35:58 2008
New Revision: 141195
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141195
Log:
fix PR tree-optimization/37102
2008-10-17 Andrew MacLeod <[E
--- Comment #19 from joseph at codesourcery dot com 2008-10-17 16:55
---
Subject: Re: can't disable __attribute__((warn_unused_result))
On Fri, 17 Oct 2008, bonzini at gnu dot org wrote:
> > In the case of fwrite, for example, the only obvious case where checking
> > would be useles
--- Comment #10 from rth at gcc dot gnu dot org 2008-10-17 16:40 ---
Created an attachment (id=16513)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16513&action=view)
proposed patch
I'm pretty sure this patch is sufficient to return this function to working
order.
I'll have a look
--- Comment #5 from mikael dot morin at tele2 dot fr 2008-10-17 16:38
---
I'v just tried r140349 and r141192.
It's not better.
--
mikael dot morin at tele2 dot fr changed:
What|Removed |Added
--
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #2 from burnus at gcc dot gnu dot org 2008-10-17 15:50 ---
Jerry, do you have an idea?
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from bonzini at gnu dot org 2008-10-17 15:48 ---
> In the case of fwrite, for example, the only obvious case where checking
> would be useless is if you already are writing an error message before
> exiting with error status and so an error writing the error message cou
--- Comment #2 from joel at gcc dot gnu dot org 2008-10-17 15:45 ---
*** This bug has been marked as a duplicate of 37815 ***
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from joel at gcc dot gnu dot org 2008-10-17 15:45 ---
*** Bug 37840 has been marked as a duplicate of this bug. ***
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from joel at gcc dot gnu dot org 2008-10-17 15:44 ---
Also happens on powerpc-rtems4.10
+===GNAT BUG DETECTED==+
| 4.4.0 20081014 (experimental) [trunk revision 141108]
(powerpc-unknown-rtems4.10) GCC error:|
| in vt_add
--- Comment #1 from domob at gcc dot gnu dot org 2008-10-17 15:42 ---
Confirmed on trunk, with this test:
program pb
write(*,'(F3.0)') 1.0d0 - 1.110223024625157D-16
end
Changing decimals display to a value larger than 0 outputs 1 correctly.
--
domob at gcc dot gnu dot org changed
--- Comment #17 from joseph at codesourcery dot com 2008-10-17 15:31
---
Subject: Re: can't disable __attribute__((warn_unused_result))
On Fri, 17 Oct 2008, bonzini at gnu dot org wrote:
> It does not matter if it is a "security" issue; if void-ifying is not an
> acceptable workaroun
--- Comment #4 from jason at redhat dot com 2008-10-17 15:18 ---
Subject: Re: DWARF output for inlined functions doesn't
always use DW_TAG_inlined_subroutine
These bits should not be generated:
<2><8c>: Abbrev Number: 8 (DW_TAG_lexical_block)
<3><8d>: Abbrev Number: 8 (DW_TAG_lex
With the code here:
program pb
character*10 form
character*4093 str
str=' '
write(form,120) 3,0
write(str(1:3),form) 1.0d0 - 1.110223024625157D-16
print *,str(1:10)
120 format('(f',i2,'.',i2,')')
end
Compiled with gfortran 4.3.2:
the outp
--- Comment #7 from krebbel at gcc dot gnu dot org 2008-10-17 13:16 ---
Same on s390x:
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00740.html
Please note that the patch attached to the email most likely isn't a correct
solution.
--
krebbel at gcc dot gnu dot org changed:
--- Comment #3 from ludovic at ludovic-brenta dot org 2008-10-17 13:06
---
This is a duplicate of PR ada/37034.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37396
--- Comment #4 from dominiq at lps dot ens dot fr 2008-10-17 12:54 ---
Looks like pr37808, supposed to be fixed at r 14178.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37850
--- Comment #3 from mikael dot morin at tele2 dot fr 2008-10-17 12:39
---
I'm at r141174.
But I don't think it is one particular revision.
I have seen this for a couple of weeks now.
I thought it would be reverted soon.
Now, I'm not sure it is a gcc bug.
I have the feeling that my
--- Comment #6 from ktietz at gcc dot gnu dot org 2008-10-17 12:25 ---
For target x86_64-pc-mingw32 it is the same
In file included from
/vol/d/sources/gcc_new/gcc_1017/build3/x86_64-pc-mingw32/libstdc++-v3/include/ostream:572,
from ../../../../libstdc++-v3/src/ostream-
--- Comment #16 from bonzini at gnu dot org 2008-10-17 11:40 ---
It does not matter if it is a "security" issue; if void-ifying is not an
acceptable workaround, there must be at the very least a Wno-* option to
disable it.
--
bonzini at gnu dot org changed:
What|Remov
--- Comment #9 from bonzini at gnu dot org 2008-10-17 11:37 ---
So I should reopen bug 25509 and leave this one for the false negatives.
--
bonzini at gnu dot org changed:
What|Removed |Added
Hello,
I ran into the following using gcc 4.2.3 on ubuntu 8.04. I ran it with
-Werror so it died on receiving this warning:
cc1: warnings being treated as errors
tux3fuse.c: In function 'tux3_lookup':
tux3fuse.c:78: warning: initialized field overwritten
tux3fuse.c:78: warning: (near initializati
--- Comment #8 from joseph at codesourcery dot com 2008-10-17 11:22 ---
Subject: Re: [4.1/4.2/4.3/4.4 Regression] casts to void do not
silence -Wunused warnings for the case of __attribute__(( warn_unused_result
))
On Fri, 17 Oct 2008, bonzini at gnu dot org wrote:
> It seems bad th
--- Comment #7 from bonzini at gnu dot org 2008-10-17 11:12 ---
Totally untested patch.
Index: c-common.c
===
--- c-common.c (revisione 134435)
+++ c-common.c (copia locale)
@@ -6762,7 +6762,8 @@ c_warn_unused_result (tre
--- Comment #6 from bonzini at gnu dot org 2008-10-17 09:14 ---
It seems bad that *explicit* casts to void cannot silence the warning. This is
a problem for projects using -Werror and using (void) with due diligence
(including GNU coreutils).
--
bonzini at gnu dot org changed:
Hi Guys,
Compiling and then executing this program:
#include
class A {
public:
virtual void get() { printf ("A\n"); }
};
class B:public A {
public:
virtual void get() { printf ("B\n"); }
};
class C:public B {
};
int main (void)
{
C c;
C* p = &c;
p->A::get();
(p->A::get)();
return 0;
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||dberlin at gcc dot gnu dot
|
extern int printf (__const char *__restrict __format, ...);
static int f2(char formatstr[10][100]) {
int anz;
for( anz = 0; anz < 10; ++anz ) {
printf( "%d %s\n", anz, formatstr[anz] );
}
return anz;
}
static char formatstr[10][100];
int main( void ) {
int an
--- Comment #1 from bkoz at gcc dot gnu dot org 2008-10-17 08:19 ---
Sorry, that should have a single argument ctor.
Like:
struct b
{
bool t;
b() = default;
~b() = default;
b& operator=(const b&) = delete;
b(const b&) = delete;
b(bool) { }
};
Gives:
%g++ -std=c++0x -c
Valid C++0x code is failing to compile. Support for default and delete appears
to be incomplete, as certain valid initialization fails. An example:
struct b
{
bool t;
b() = default;
~b() = default;
b& operator=(const b&) = delete;
b(const b&) = delete;
};
int main()
{
// copy initial
--- Comment #5 from cnstar9988 at gmail dot com 2008-10-17 07:30 ---
4.3 branch has the same bug...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37805
46 matches
Mail list logo
