--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29025
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-12 06:37 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2006-09-12 06:35
---
I've never been able to reproduce this. Do you still have the problem with
the 4.x series of compiler?
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |major
Summary|All error messages produce |[4.0/4.1/4.2
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot
|dot org
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-09-12 06:29
---
Confirmed, known problem in the 4.x series of compilers.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-09-12 06:29 ---
*** Bug 26609 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23086
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-12 06:29 ---
Yes it is a dup, looking at the tree dump even with changing void * to int*
does not make it work.
*** This bug has been marked as a duplicate of 23086 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-12 06:25 ---
Confirmed, LIM works correctly though.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-09-12 06:18
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-12 05:57 ---
Simple untested (even on the testcase) fix:
Index: rs6000.c
===
--- rs6000.c(revision 116799)
+++ rs6000.c(working copy)
@@ -4607,7 +4607,10 @@
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-12 05:55 ---
"X" (*str)
We need a temporary here because *str can be modified inside the asm and we
don't know that you want it in a memory or a register.
Anyways using "m"(*str) instead changes that and fixes your issue.
Since
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-12 05:49 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-12 05:46 ---
Backtrace:
#0 0x08106fb5 in build_vfield_ref (datum=0xb7d6d760, type=0xb7da16d4) at
../../gcc/cp/class.c:554
#1 0x081063b3 in build_base_path (code=PLUS_EXPR, expr=0xb7d6d720,
binfo=0xb7ff5800, nonnull=1)
at ..
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-12 05:44 ---
Confirmed, backtrace:
(gdb) bt
#0 0x08056d6f in add_candidates (fns=0xb7d536d8, args=0x0,
explicit_targs=0xb7d537c8,
template_only=1 '\001', conversion_path=0x0, access_path=0x0, flags=3,
candidates=0xbf952f64)
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-12 05:42 ---
bits/atomicity.h now does on the mainline:
#include
#include
So fixed for 4.2.0 by:
r108775 | bkoz | 2005-12-18 16:56:05 -0800 (Sun, 18 Dec 2005) | 334 lines
2005-12-18 Benjamin Kosnik <[EMAIL PROTECTED]>
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-12 05:30 ---
Do you have a testcase which you are willing to share with us?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #14 from hjl at lucon dot org 2006-09-12 05:34 ---
Fixed.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-12 05:26 ---
Subject: Bug 29007
Author: pinskia
Date: Tue Sep 12 05:26:45 2006
New Revision: 116872
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116872
Log:
2006-09-11 Andrew Pinski <[EMAIL PROTECTED]>
PR te
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-12 05:25 ---
Also 4.1.2.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-12 05:16 ---
This is a host issue. I don't think host-darwin.c has been ported at all to
64bits.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-12 05:10 ---
Fixed for at least 4.1.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27530
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2006-09-12
04:54 ---
Created an attachment (id=12234)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12234&action=view)
assembly file for cleanup-10.c created on Darwin PPC at -m64
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2006-09-12
04:53 ---
Created an attachment (id=12233)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12233&action=view)
preprocessed file for cleanup-10.c generated on Darwin PPC at -m64
--
http://gcc.gnu.org/bugzilla
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28993
--- Comment #8 from pault at gcc dot gnu dot org 2006-09-12 04:38 ---
Fixed on trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28971
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-12 04:50 ---
The assembly code looks fine for me, though I might had missed something.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
The gcc.dg/array-9.c testcase results in an internal compiler error on
powerpc-apple-darwin8 when compiled at -m64.
gcc-4 -O3 -m64 array-9.c
array-9.c:7: error: declaration of 'x' as array of voids
array-9.c: In function 'foo':
array-9.c:10: internal compiler error: tree check: expected class 'typ
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2006-09-12
04:17 ---
Created an attachment (id=12230)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12230&action=view)
preprocessed file for array-9.s generated with -O3 -m64 on Darwin PPC
--
http://gcc.gnu.org/bugzi
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24334
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2006-09-12
04:42 ---
Created an attachment (id=12231)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12231&action=view)
preprocessed file for array-9.s generated with -O3 -m64 on Darwin PPC
--
http://gcc.gnu.org/bugzi
share/info --with-gmp=/sw --with-included-gettext
--host=powerpc-apple-darwin8 --with-libiconv-prefix=/sw
Thread model: posix
gcc version 4.2.0 20060911 (experimental)
--
Summary: gcc.dg/asm-b.c execution test aborts at -m64 on
powerpc-apple-darwin8
Pr
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28959
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2006-09-12
04:20 ---
Andrew,
I'd be happy to test any attempts to fix this.
Jack
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29030
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-12 05:21 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-12 04:59 ---
No feedback in 3 months so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-languages=c,c++,fortran
--infodir=/sw/lib/gcc4/share/info --with-gmp=/sw --with-included-gettext
--host=powerpc-apple-darwin8 --with-libiconv-prefix=/sw
Thread model: posix
gcc version 4.2.0 20060911 (experimental)
--
Summary: gcc.dg/cleanup-10.c execution test times out on powerpc
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-12 04:16 ---
This is a target specific issue, I might fix this even though I don't have any
way of testing the fix (except maybe for changing the ABI on powerpc-linux-gnu
to use the darwin64 struct passing ABI).
--
pinskia at
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2006-09-12
04:43 ---
Created an attachment (id=12232)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12232&action=view)
assembly file asm-b.s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29031
--- Comment #7 from pault at gcc dot gnu dot org 2006-09-12 04:37 ---
Subject: Bug 28890
Author: pault
Date: Tue Sep 12 04:37:09 2006
New Revision: 116871
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116871
Log:
2006-09-12 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-12 05:19 ---
6496 /* Only operator new(...) throw(), can return NULL [expr.new/13]. */
6497 if ((DECL_OVERLOADED_OPERATOR_P (current_function_decl) == NEW_EXPR
6498 || DECL_OVERLOADED_OPERATOR_P (current_func
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-12 04:06 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from bangerth at dealii dot org 2006-09-12 04:00 ---
(In reply to comment #4)
> I suppose this is the same basic problem?
No, that code is definitely legal and unobjectionable. Just as having two
extern declarations of the same variable in the same scope (or two forward
d
--- Comment #1 from bangerth at dealii dot org 2006-09-12 03:58 ---
At first I thought that the warning is not useful since the variable may
in fact not be unused at all -- the using declaration simply makes the
name available in the present scope.
However, then I realized that this als
--- Comment #14 from hjl at gcc dot gnu dot org 2006-09-12 02:54 ---
Subject: Bug 27537
Author: hjl
Date: Tue Sep 12 02:54:42 2006
New Revision: 116870
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116870
Log:
gcc/
2006-09-11 H.J. Lu <[EMAIL PROTECTED]>
PR target/13
--- Comment #23 from hjl at gcc dot gnu dot org 2006-09-12 02:54 ---
Subject: Bug 13685
Author: hjl
Date: Tue Sep 12 02:54:42 2006
New Revision: 116870
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116870
Log:
gcc/
2006-09-11 H.J. Lu <[EMAIL PROTECTED]>
PR target/13
--- Comment #13 from hjl at gcc dot gnu dot org 2006-09-12 02:54 ---
Subject: Bug 28621
Author: hjl
Date: Tue Sep 12 02:54:42 2006
New Revision: 116870
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116870
Log:
gcc/
2006-09-11 H.J. Lu <[EMAIL PROTECTED]>
PR target/13
--- Comment #5 from janis at gcc dot gnu dot org 2006-09-12 00:42 ---
Subject: Bug 28950
Author: janis
Date: Tue Sep 12 00:42:27 2006
New Revision: 116868
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116868
Log:
2006-09-11 Jack Howarth <[EMAIL PROTECTED]>
PR testsui
--- Comment #15 from hjl at lucon dot org 2006-09-12 00:35 ---
Fixed:
http://gcc.gnu.org/ml/gcc-testresults/2006-09/msg00586.html
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #4 from janis at gcc dot gnu dot org 2006-09-12 00:34 ---
Subject: Bug 28950
Author: janis
Date: Tue Sep 12 00:34:18 2006
New Revision: 116867
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116867
Log:
2006-09-11 Jack Howarth <[EMAIL PROTECTED]>
PR testsui
--- Comment #5 from sebor at roguewave dot com 2006-09-12 00:16 ---
The reason why I think library issue 309 may be relevant is because while the
arithmetic extraction operator>>() is a formatted input function (and thus
subject to 27.6.1.1, p4, and required to begin by constructing a se
--- Comment #6 from tromey at gcc dot gnu dot org 2006-09-11 23:26 ---
Thanks for the updated test.
It fails for me if I compile it to .class with ecj, but not
if I compile it to .class with gcj.
The difference is in the qualification of the reference to
SUFFIX_CLASS in test2 .. ecj ge
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-09-11 23:11
---
Fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28672
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-09-11 23:01
---
> Thank you for the fix. And for serving the GCC to the community. :)
You're welcome. Thanks for reporting the problem and for the nice testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28726
--- Comment #5 from bero at arklinux dot org 2006-09-11 23:00 ---
Created an attachment (id=12229)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12229&action=view)
Real test case
Oops, must have attached the wrong file, that was the test case for a much
older problem (PR24598, whi
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #15 from sje at cup dot hp dot com 2006-09-11 22:31 ---
Bryce, have you looked at ifdef'ing the use of _Unwind_GetIPInfo in the Java
library? Would you be willing to do so? I have created an autoconf test
(GCC_CHECK_UNWIND_GETIPINFO) in trunk/config/unwind_ipinfo.m4 and the
--- Comment #4 from jimrees at itasoftware dot com 2006-09-11 22:23 ---
Sure, the issue sounds interesting, and the committee's resolution statement is
definitely lame. Bug issue 309 seems to be more about what is _specified_
about sentry::sentry()'s behavior, and I don't necessarily c
[EMAIL PROTECTED] gujin]$ cat tmp.c
#include
typedef struct {
unsigned short data[3];
union diskcmd {
unsigned udata[5];
unsigned char cdata[20];
} cmd;
} bootloader2_t;
bootloader2_t uninstall_mbr;
extern inline unsigned char
BOOT1_diskread (union diskcmd *s
I suppose it would make sense to emit a -Wunused warning for this code:
namespace N
{
int i;
}
void
f ()
{
using N::i;
}
--
Summary: No warning about unused names introduced with using
declarations
Product: gcc
Version: 4.2.0
--- Comment #4 from amylaar at gcc dot gnu dot org 2006-09-11 21:45 ---
I suppose this is the same basic problem?
namespace N
{
int i;
}
void
f ()
{
using N::i;
using N::i;
}
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #22 from hjl at gcc dot gnu dot org 2006-09-11 21:34 ---
Subject: Bug 13685
Author: hjl
Date: Mon Sep 11 21:34:06 2006
New Revision: 116860
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116860
Log:
gcc/
2006-09-11 H.J. Lu <[EMAIL PROTECTED]>
PR target/13
--- Comment #12 from hjl at gcc dot gnu dot org 2006-09-11 21:34 ---
Subject: Bug 28621
Author: hjl
Date: Mon Sep 11 21:34:06 2006
New Revision: 116860
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116860
Log:
gcc/
2006-09-11 H.J. Lu <[EMAIL PROTECTED]>
PR target/13
--- Comment #13 from hjl at gcc dot gnu dot org 2006-09-11 21:34 ---
Subject: Bug 27537
Author: hjl
Date: Mon Sep 11 21:34:06 2006
New Revision: 116860
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116860
Log:
gcc/
2006-09-11 H.J. Lu <[EMAIL PROTECTED]>
PR target/13
--- Comment #13 from hjl at gcc dot gnu dot org 2006-09-11 21:30 ---
Subject: Bug 28672
Author: hjl
Date: Mon Sep 11 21:30:07 2006
New Revision: 116859
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116859
Log:
2006-09-11 Alexandre Oliva <[EMAIL PROTECTED]>
PR target/
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-11 21:27 ---
Confirmed, not a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from sebor at roguewave dot com 2006-09-11 21:25 ---
This sounds like it might be related to
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309. If so, and if
this case is important to you (the submitter) it might be helpful to give the
committee a little nudg
According to clauses 7.3.3 ; 4 and 14.5.2 ; 7, the using declaration below
should elicit a diagnostic, since template conversion function specializations
are not supposed to be found by name lookup.
struct B
{
template < class T > operator T ();
};
struct D: B
{
using B::operator int;
};
--
--- Comment #2 from jimrees at itasoftware dot com 2006-09-11 21:10 ---
fyi, a "real world" example of how this comes up? Construct a std::ifstream
using a pathname to a directory instead of a file. Under Linux and MacOS at
least, the basic_filebuf code is happy to open such a pathna
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |daney at gcc dot gnu dot org
|dot org
--- Comment #1 from jimrees at itasoftware dot com 2006-09-11 21:07 ---
Created an attachment (id=12228)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12228&action=view)
bug reproducer program
bug reproducer, compile with g++ - any flags, but do not disable exceptions.
--
htt
27.6.1.1 P4 says that formatted input functions should set badbit if a call to
fetch characters from the streambuf throws an exception.
The implementation of this in bits/istream.tcc is done after the sentry is
constructed. But the sentry's constructor may try to read whitespace, and it
is not do
--- Comment #7 from sg313d at gmail dot com 2006-09-11 20:57 ---
Thank you for the fix. And for serving the GCC to the community. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28726
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-11 20:50 ---
Confirmed, a regression from 3.4.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-11 20:48 ---
Fixed in 4.0.4 20060622.
This was either a dup of bug 26729 or bug 28045.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from sje at cup dot hp dot com 2006-09-11 20:39 ---
It looks like this failure was introduced with r115620.
+2006-07-20 Paul Brook <[EMAIL PROTECTED]>
+
+ Backport from mainline.
+ PR 27363
+ * cse.c (cse_insn): Add destination addresses to hash table
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29025
--- Comment #1 from mbo dot massimo at tiscali dot it 2006-09-11 20:36
---
Created an attachment (id=12227)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12227&action=view)
source files to reproduce the problem
source file necessary to reproduce the bug.
Use gcc -S pkg_test.adb c
GCC configure data:
system type... i686-pc-cygwin
target system type... powerpc-xcoff-lynxos
build system type... i686-pc-cygwin
gcc -v
Reading specs from
/cross_compiler/tools/cygwin_ppc_gnu/lib/gcc/ppc-xcoff-lynxos/4.1.1/specs
Target: ppc-xcoff-lynxos
Configured with: gcc-4.1.1/configure --targe
--- Comment #8 from sgk at troutmask dot apl dot washington dot edu
2006-09-11 20:31 ---
Subject: Re: EXPONENT() broken for real constants
On Mon, Sep 11, 2006 at 07:33:35PM -, sgk at troutmask dot apl dot
washington dot edu wrote:
>
> I should also note that the parsing is corre
The following requires a diagnostic:
typedef static int T;
--
Summary: storage class specifier accepted for typedef (clause
7.1.1 ; 1)
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: accepts-invalid
S
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --enable-languages=c,c++,objc
--prefix=/software/linux/gcc/4.0.3
Thread model: posix
gcc version 4.0.3
The bug shows up with options -Os or -Ox (x >= 1). Here is the source file:
main () {
unsigned char t1[1];
t
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-09-11 19:50 ---
(In reply to comment #2)
> Please provide a testcase as well as the other required bits of info.
>
This is a stripped down cc1plus testcase:
void
f (unsigned char *a, int &i)
{
i = a[0] << 8 & a[1];
}
This does
--- Comment #13 from dannysmith at users dot sourceforge dot net
2006-09-11 19:47 ---
In my sources for David Gay's gdtoa implemntation it say this:
/* On a machine with IEEE extended-precision registers, it is
* necessary to specify double-precision (53-bit) rounding precision
* befo
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29022
The following invalid code snippet triggers a segfault since GCC 3.4.0:
==
struct A
{
operator int();
};
struct B : virtual A, A<0> {};
int foo(B &b)
{
return b;
}
==
bug.cc:6: error: expected te
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29020
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29021
The following invalid code snippet triggers a segfault since GCC 3.4.0:
==
struct A
{
template void foo()
{
A().template *foo<0>();
}
};
==
bug.cc: In member function 'void A::foo()':
bug.cc:
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu
2006-09-11 19:33 ---
Subject: Re: EXPONENT() broken for real constants
On Mon, Sep 11, 2006 at 07:19:41PM -, sgk at troutmask dot apl dot
washington dot edu wrote:
>
> gfortran is calling the wrong libm function.
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-09-11 19:32
---
Fixed in upcoming 4.1.2 release.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-09-11 19:28
---
Subject: Bug 28726
Author: ebotcazou
Date: Mon Sep 11 19:28:41 2006
New Revision: 116856
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116856
Log:
PR rtl-optimization/28726
* sched-deps.c
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-09-11 19:28
---
Subject: Bug 28726
Author: ebotcazou
Date: Mon Sep 11 19:28:11 2006
New Revision: 116855
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116855
Log:
PR rtl-optimization/28726
* sched-deps.c
The following (IMHO valid) code snippet triggers a segfault since GCC 3.4.0:
==
template struct A
{
void foo();
};
struct B
{
template friend void A::A::foo();
};
==
x1.cc:8: internal compiler
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu
2006-09-11 19:19 ---
Subject: Re: EXPONENT() broken for real constants
On Sun, Sep 10, 2006 at 10:43:21PM -, tobias dot burnus at physik dot
fu-berlin dot de wrote:
>
> Comment #5 from tobias dot burnus at physik
Hello, Excuse me for my English because I learn English. I have found a bug for
convert a *.java to *.exe. When I would like use getCanonicalPath()or
getCanonicalFile() from class File in Java, I have a different results with the
*.class and the *.exe. I use Windows XP Home Edition. Can you contact
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-11 18:56 ---
http://gcc.gnu.org/ml/gcc-cvs/2006-09/msg00240.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from aldot at gcc dot gnu dot org 2006-09-11 18:26 ---
-pedantic-errors also has no effect. From a quick look, it does not occur in
fortran/* at all and should probably be removed.
I'm preparing an updated patch to add proper -Werror support that emits
'Warning' for warni
1 - 100 of 139 matches
Mail list logo
