--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-31 07:56 ---
t.cc: In function float __vector__ nova::detail::gen_one():
t.cc:34160: warning: x is used uninitialized in this function
inline __m128 gen_one(void)
{
__m128i x;
__m128i ones = _mm_cmpeq_epi32(x, x);
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-31 07:49 ---
>ulong ConnectCB(GtkWidget* pWidget, const char* sigName,
> _R(_ClassType::*MemFun)(GtkWidget*, _A1))
> {
>typedef CBFamily2<_ClassType, _R, GtkWidget*, _A1, MemFun>
> TCallbackType;
Th
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-31 07:47 ---
sys_perf_counter_open always returns less than zero for me.
This is with:
Linux gcc13 2.6.18-6-vserver-amd64 #1 SMP Sun Feb 10 17:55:04 UTC 2008 x86_64
GNU/Linux
What system call is it trying to do and why?
--
--- Comment #2 from juvvij at gmail dot com 2008-12-31 07:43 ---
Created an attachment (id=17018)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17018&action=view)
Details of gcc from output of g++ -v -save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38681
--- Comment #1 from juvvij at gmail dot com 2008-12-31 07:42 ---
Created an attachment (id=17017)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17017&action=view)
Preprocessed test case that causes the compiler error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38681
While trying to reinvent some suitablu smart technique for routing Gtk's static
callbacks to object methods, I thought I had created a suitably brilliant
solution. Gcc could not digest it. While I am looking at smarter solutions from
boost or loki, I would like to see if I really was onto a workabl
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-31 03:17 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-12-31 01:40 ---
(In reply to comment #5)
> Reverting is a bad approach. We IMHO just want to check for
> TREE_CODE (type) == REFERENCE_TYPE and issue diagnostics that references can't
> be value-initialized.
Yes that seems like a
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-31 01:35 ---
The only reason why you might need this is to support headers.
Also you can use the {} syntax for inline assembly to support alternative
writing of the instructions.
An example is:
"add{q}\t{%2, %0|%0, %2}"
--
to allow compatibility error checking, and also maybe to enable conditional
".intel_syntax" ... ".att_syntax" bracketing, it might be helpful if the -masm=
switch defined a preprocessor variable to indicate the top level syntax?
--
Summary: -masm= option might usefully define a prepro
extern volatile int x;
extern fff(int);
int f() {
fff(x=1);
return x=1;
}
#if 0
The code generated by gcc below from the source code above shows that the value
of the expression x=1, when x is volatile, depends on the context, most likely
violating the standard.
In a return statement, the va
--- Comment #3 from rob1weld at aol dot com 2008-12-31 00:49 ---
Right.
(In reply to comment #2)
> The .java source part of the java front-end was removed in 4.3.x and above so
> closing as won't fix.
>
(In comment #0 Rob said)
>> _THIS_ bug report is only on "Unreachable statement" t
--- Comment #1 from paolo dot carlini at oracle dot com 2008-12-31 00:06
---
Ok, thanks.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Assi
--- Comment #3 from jakub at gcc dot gnu dot org 2008-12-30 23:55 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Assi
--- Comment #2 from jakub at gcc dot gnu dot org 2008-12-30 23:53 ---
Subject: Bug 38640
Author: jakub
Date: Tue Dec 30 23:52:06 2008
New Revision: 142973
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142973
Log:
PR c++/38640
* semantics.c (finish_decltype_type)
--- Comment #8 from jakub at gcc dot gnu dot org 2008-12-30 23:35 ---
Subject: Bug 38505
Author: jakub
Date: Tue Dec 30 23:34:28 2008
New Revision: 142972
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142972
Log:
PR middle-end/38505
* tree-ssa-ccp.c (may_propaga
--- Comment #4 from jakub at gcc dot gnu dot org 2008-12-30 23:32 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from jakub at gcc dot gnu dot org 2008-12-30 23:22 ---
Subject: Bug 38676
Author: jakub
Date: Tue Dec 30 23:20:45 2008
New Revision: 142970
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142970
Log:
PR middle-end/38676
* gimplify.c (gimple_regimpli
--- Comment #4 from paolo dot carlini at oracle dot com 2008-12-30 22:59
---
Ok, let's close this one.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from mikael at gcc dot gnu dot org 2008-12-30 22:47 ---
An other failure:
use iso_c_binding
type t1
integer :: i(5)
end type t1
type t2
type(t1) :: t(5)
end type t2
character(len=2),target :: str(2)
type(t2), target :: tt
type(C_PTR) :
As mentioned in bug 38476, [lib.istream], p2 specifies that:
Both [formatted and unformatted] input functions are described as if
they obtain (or extract) input characters by calling rdbuf()->sbumpc()
or rdbuf()->sgetc(). They may use other public members of istream.
sgetc() is required to
--- Comment #14 from pinskia at gcc dot gnu dot org 2008-12-30 22:22
---
My patch is causing a couple of regressions:
FAIL: g++.dg/template/non-dependent8.C (test for errors, line 20)
FAIL: g++.dg/template/overload2.C (test for excess errors)
FAIL: g++.old-deja/g++.pt/ptrmem6.C (test
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2008-12-30
22:21 ---
Subject: Re: FAIL: gfortran.dg/parameter_array_init_3.f90 -O (internal
compiler error)
> > Is backporting the fix for PR fortran/35840, or just gfc_reduce_init_expr,
> > that difficult?
> No, it should b
--- Comment #4 from mikael at gcc dot gnu dot org 2008-12-30 22:12 ---
(In reply to comment #3)
> Is backporting the fix for PR fortran/35840, or just gfc_reduce_init_expr,
> that difficult?
No, it should be manageable.
I gave up when the patch refused to apply. Sorry.
I could try harde
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.4.0
Known to work||4.3.2
gcc 4.3.1 fails to diagnose the following ill-formed program:
template struct S { T foo (); };
template T S::foo () { return T (); }
template struct S;
extern template struct S;
int main () { return S().foo (); }
See the discussion thread below for more detail:
John H. Spicer wrote:
>
> On
--
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 #2 from il dot basso dot buffo at gmail dot com 2008-12-30
21:43 ---
This is actually an ultra-condensed example of a GCC 4.4.0 build failure in
ImageMagick.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38676
--enable-cld --enable-java-awt=gtk --enable-languages=c,c++,java,fortran
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion=
Thread model: posix
gcc version 4.4.0-pre built 20081230 (Gentoo SVN ebuild
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2008-12-30
21:40 ---
Subject: Re: FAIL: gfortran.dg/parameter_array_init_3.f90 -O (internal
compiler error)
> Given the last comment. This will probably be closed with a WONTFIX.
Is backporting the fix for PR fortran/35840
--
Summary: GCC 4.4 ICE on OpenMP shared
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: il dot ba
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-12-30 21:26 ---
Yes, but you are adjusting libdir. I have no problems with just using --prefix
on alternate compilers. But well, I don't have an idea what is really going
wrong. You can try passing -v to the failing command and s
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-12-30 21:21 ---
Subject: Bug 38645
Author: rguenth
Date: Tue Dec 30 21:20:08 2008
New Revision: 142967
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142967
Log:
2008-12-30 Richard Guenther
PR tree-optimization/
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-12-30 21:20 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from kargl at gcc dot gnu dot org 2008-12-30 21:15 ---
See PR 37469
Given the last comment. This will probably be closed with a WONTFIX.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from danglin at gcc dot gnu dot org 2008-12-30 21:03 ---
(gdb) p *p
$2 = {expr_type = EXPR_ARRAY, ts = {type = BT_INTEGER, kind = 1,
derived = 0x0, cl = 0x0, is_c_interop = 0, is_iso_c = 0,
f90_type = BT_UNKNOWN}, rank = 0, shape = 0x800100131b58,
symtree
This bug has been around for awhile on the 4.3 branch. Not present in 4.4.
Executing on host: /mnt/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B/
mnt/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
/mnt/gnu/gcc/gcc/gcc/testsuite/
gfortran.dg/parameter_array_init_3.f90 -O -pedantic-erro
--- Comment #5 from jakub at gcc dot gnu dot org 2008-12-30 20:19 ---
Seongbae reverted the patch, so this is no longer broken on darwin.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from sebor at roguewave dot com 2008-12-30 20:08 ---
Quoting [lib.istream], p2:
Both [formatted and unformatted] input functions are described as if
they obtain (or extract) input characters by calling rdbuf()->sbumpc()
or rdbuf()->sgetc(). They may use other public
--- Comment #5 from imam dot toufique at intel dot com 2008-12-30 19:52
---
(In reply to comment #3)
> --libdir="${INSTALL_PREFIX}"/"${PLATFORM_LIBDIR}"
> this adjusts the std search paths (as well as --prefix), so you need to put a
> libc there as well. You probably want to add --with
--- Comment #4 from imam dot toufique at intel dot com 2008-12-30 19:51
---
(In reply to comment #3)
> --libdir="${INSTALL_PREFIX}"/"${PLATFORM_LIBDIR}"
> this adjusts the std search paths (as well as --prefix), so you need to put a
> libc there as well. You probably want to add --with
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38669
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-12-30 19:12 ---
--libdir="${INSTALL_PREFIX}"/"${PLATFORM_LIBDIR}"
this adjusts the std search paths (as well as --prefix), so you need to put a
libc there as well. You probably want to add --with-sysroot=/ to the configure
line.
--- Comment #2 from imam dot toufique at intel dot com 2008-12-30 19:06
---
(In reply to comment #1)
> /opt/gcc/4.3.2/i686-pc-linux-gnu/bin/ld: cannot find -lc
> you are likely missing the glibc-devel package.
Hi, I have the glibc-devel installed, I verified it.
host> rpm -qa | grep g
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-30 17:50 ---
I have not built 4.2.x recently but I know the trunk works for Darwin 10.4.11.
I also know 4.3.0 and above work, Can you try 4.3.2?
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-12-30 17:27
---
>but I'm not quite sure if it still reproduces the original issue
Yes it does, I had missed your reduced testcase before.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-12-30 17:25
---
Here is a reduced testcase which is rejected for both -m32 and -m64:
typedef unsigned long size_t;
templateclass array {};
typedef unsigned int uint;
template
struct my_table: array {};
template
inline cons
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-12-30 17:13 ---
I have a simple fix, the front-end should have already warned about the
conversion from a pointer to a member object to an integer type. Therefor
convert can handle OFFSET_TYPE just like INTEGER_TYPE and such.
--
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
CC||jamborm at gcc dot gnu dot
|
--- Comment #3 from jamborm at gcc dot gnu dot org 2008-12-30 16:58 ---
I discussed this bug with Richi on IRC and was told that we should
avoid having the statement marked as volatile since it is not an
access through a volatile variable in the original source code.
Ins
--- Comment #3 from burnus at gcc dot gnu dot org 2008-12-30 16:50 ---
Works with 4.2.1 (x86_64-suse-linux). Valgrind shows:
==27337== Invalid read of size 1
==27337==at 0x4752E2: resolve_symbol (resolve.c:9311)
==27337==by 0x482726: traverse_ns (symbol.c:3127)
==27337==by 0
--- Comment #4 from mikael at gcc dot gnu dot org 2008-12-30 16:45 ---
Created an attachment (id=17016)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17016&action=view)
fix
Does anyone know the use of the block variable I remove in this patch?
--
mikael at gcc dot gnu dot org
--- Comment #7 from rguenther at suse dot de 2008-12-30 16:33 ---
Subject: Re: SLES11: SEGV with try/throw/catch/terminate()
at -q64
On Tue, 30 Dec 2008, pinskia at gcc dot gnu dot org wrote:
> --- Comment #6 from pinskia at gcc dot gnu dot org 2008-12-30 16:31
> ---
> (In
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-12-30 16:31 ---
(In reply to comment #5)
> Yes, what I wanted to say/ask is if it is powerpc64, as there are some known
> (but yet uninvestigated) EH failures on that arch.
There are? I have not seen any. Could it be because of b
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-30 16:28 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-30 16:28 ---
Subject: Bug 38661
Author: pinskia
Date: Tue Dec 30 16:27:29 2008
New Revision: 142964
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142964
Log:
2008-12-30 Andrew Pinski
PR middle-end/38661
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|inline-asm |target
GCC target triplet||i?86-*-*
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-30 16:13 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-30 16:13 ---
As mentioned at http://gcc.gnu.org/ml/gcc-patches/2008-12/msg01259.html .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38673
When compiling the following code with -O2:
#include
static unsigned long long __attribute__((noinline)) f(void *ptr, unsigned long
long ull)
{
register unsigned long __r2 __asm__ ("r2") = (unsigned long) (&ull);
__asm__ __volatile__ ("" : "+r" (__r2));
return * (unsigned
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2008-12-30
15:23 ---
I understand Mike Stump's previous comments on this, the possible solutions are
to...
Another possibility, would be to split out the tls emulation package from
gcc_eh. We avoid gcc_eh, so as to not pull in
--- Comment #3 from mikael at gcc dot gnu dot org 2008-12-30 15:02 ---
At revision 142760, there is no temporary, so there is no bug.
That's something I missed in my patch, that's true.
The bug is still there however.
Change this:
call tq_tvgh (var_f% av (k_lev:,1), p(k_lev:))
to th
--- Comment #7 from irar at il dot ibm dot com 2008-12-30 14:57 ---
(In reply to comment #6)
> t.i:3: note: Vectorization may not be profitable.
> why doesn't the cost model then disallow vectorization here?
This is misleading. It only means that there exists loop bound threshold either
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-12-30
14:52 ---
This is also showing up in the testresults on i686-apple-darwin9.
--
howarth at nitro dot med dot uc dot edu changed:
What|Removed |Added
The g++.dg/tree-prof/indir-call-prof.C test case no longer compiles on
powerpc-apple-darwin8.5.0. It now produces the error...
Executing on host: /Users/regress/tbox/native/build/gcc/testsuite/g++/../../g++
-B/Users/regress/tbox/native/build/gcc/testsuite/g++/../../
/Users/regress/tbox/svn-gcc/gcc
--- Comment #9 from ubizjak at gmail dot com 2008-12-30 14:45 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2008-12/msg01280.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #1 from vmakarov at redhat dot com 2008-12-30 14:33 ---
I don't think that the problem occurred because of transition to IRA. The old
register allocator (-fno-ira) uses about the same size conflict table and peak
virtual memory (it is 9230MB for the old RA on this case). S
--- Comment #2 from mikael at gcc dot gnu dot org 2008-12-30 14:04 ---
without derived types:
program gfcbu84_main
! use gfcbug84
implicit none
integer :: jplev, k_lev
real :: p(42)
real, pointer :: q(:)
jplev = 42
k_lev = 1
allocate (q(jplev))
call tq_tvgh (q(
--- Comment #3 from andreast at gcc dot gnu dot org 2008-12-30 13:41
---
Proposed patch here:
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg01279.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35460
--- Comment #5 from steven at gcc dot gnu dot org 2008-12-30 13:37 ---
We should not use the full bin-packing algorithm for any optimization level. A
simpler heuristic is called for. I'll see if I can come up with something.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38584
--- Comment #4 from steven at gcc dot gnu dot org 2008-12-30 13:36 ---
Subject: Bug 38584
Author: steven
Date: Tue Dec 30 13:35:00 2008
New Revision: 142963
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142963
Log:
PR middle-end/38584
* ipa-inline.c (compute_inl
--- Comment #5 from dragan at plusplus dot co dot yu 2008-12-30 13:20
---
The standard says that the friend declaration should inject the name 'func'
into the enclosing namespace, but in a way that it can be found only by ADL.
Here is a test case without templates:
struct Foo
{
fr
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |andreast at gcc dot gnu dot
|dot org
--- Comment #2 from tom dot browder at gmail dot com 2008-12-30 13:11
---
Created an attachment (id=17015)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17015&action=view)
Archive with files to demonstrate the bug.
The Makefile has a variable at the top to pick specific (or not)
--- Comment #1 from tom dot browder at gmail dot com 2008-12-30 13:09
---
Created an attachment (id=17014)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17014&action=view)
Output from gfortan -v
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38672
--- Comment #2 from jamborm at gcc dot gnu dot org 2008-12-30 13:08 ---
Apparently, the problem is that when some expression arithmetics is
folded to D.1241_18 = a[0], the statement volatile flag is not set
which triggers the assert.
The following simple patch makes the ICE go
The attached archive (Makefile, 2 source files, and output from gfortran -v)
yields an ICE during build with versions 4.3.2 and 4.4-20081226 (but not
version 4.1.2 20070925 (Red Hat 4.1.2-27)).
--
Summary: ICE during build with versions 4.3.2 and 4.4-20081226
Product: gcc
--- Comment #1 from tim at klingt dot org 2008-12-30 12:58 ---
Created an attachment (id=17013)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17013&action=view)
preprocessed source (gcc-4.4)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38671
i experience some speed regressions with gcc-4.4, with sse intrinsics on a
core2 (x86_64). the code is:
namespace detail
{
/** compute x1 * (1 + x2 * amount) */
__m128 inline amp_mod4_loop(__m128 x1, __m128 x2, __m128 amount, __m128 one)
{
return _mm_mul_ps(x1,
_mm_add_p
--- Comment #6 from q at ping dot be 2008-12-30 12:44 ---
So are you saying that because in an unrelated part of the code there is an
aliasing bug gcc can miscompile anything else, even if -fno-strict-aliasing is
used?
The problem is in the PLy_spi_execute_plan() function. oldcontext e
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-12-30 11:55 ---
Maybe:
r142766 | mikael | 2008-12-15 19:08:42 +0100 (Mon, 15 Dec 2008) | 14 lines
Added Mikael as CC.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-12-30 11:52 ---
14.6.5 [temp.inject]
suggests that this is valid. EDG doesn't agree with that in strict-ansi mode.
t2.C(9): error: identifier "B" is undefined
B some_function(); // B should not be declared here
^
compilatio
--- Comment #6 from rguenther at suse dot de 2008-12-30 11:46 ---
Subject: Re: Weird name-lookup error
On Tue, 30 Dec 2008, dragan at plusplus dot co dot yu wrote:
> --- Comment #4 from dragan at plusplus dot co dot yu 2008-12-30 11:42
> ---
> Please see my bug report #34870
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-12-30 11:44 ---
*** This bug has been marked as a duplicate of 34870 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-12-30 11:44 ---
IMHO the friend declaration isn't a declaration for func.
At least it shouldn't inject the name into Foo.
EDG agrees with me here:
icpc -S t.C -strict_ansi
t.C(12): error: identifier "func" is undefined
func(x)
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-12-30 11:44 ---
*** Bug 34827 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34870
--- Comment #4 from dragan at plusplus dot co dot yu 2008-12-30 11:42
---
Please see my bug report #34870. There are references to discussions
and other sources that show why this code is valid.
Hm... Apparently, this is exactly my test case. :-D
--
http://gcc.gnu.org/bugzilla/sho
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu dot
|
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-12-30 11:16 ---
(In reply to comment #1)
> Strange to say, this depends on the bittian-ness.
> On x86_64-unknown-linux-gnu with -m32 and on i686-pc-linux-gnu, I get
> the behavior described.
> On x86_64-unknown-linux-gnu without -m3
--- Comment #4 from jakub at gcc dot gnu dot org 2008-12-30 11:12 ---
See PR37302. Your testcase is invalid.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2008-12-30 11:07 ---
The patch looks good to me. Have you (or could you if not) posted it to
gcc-patches for review?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37877
--- Comment #3 from tim at klingt dot org 2008-12-30 10:58 ---
(In reply to comment #2)
> Created an attachment (id=17012)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17012&action=view) [edit]
> possible reduced test case
hm, i am not sure, whether this is a compiler bug, or a s
--- Comment #2 from tim at klingt dot org 2008-12-30 10:56 ---
Created an attachment (id=17012)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17012&action=view)
possible reduced test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38670
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-12-30 10:45 ---
/opt/gcc/4.3.2/i686-pc-linux-gnu/bin/ld: cannot find -lc
you are likely missing the glibc-devel package.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38667
--- Comment #1 from tim at klingt dot org 2008-12-30 10:42 ---
Created an attachment (id=17011)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17011&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38670
--- Comment #4 from ludovic at ludovic-brenta dot org 2008-12-30 10:42
---
Jörgen Tegnér reports:
gnatmake test_41.adb
gcc-4.3 -c test_41.adb
+===GNAT BUG DETECTED==+
| 4.3.2 (i486-pc-linux-gnu) in gimplify_expr, at gimplify.c:6314
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-12-30 10:42 ---
EDG reports (in strict-ansi mode - otherwise the friend decl injects the name)
icpc -S t.C -strict_ansi
t.C(12): error: identifier "func" is undefined
func(x);
^
t.C(12): error: type name is not allowed
(sorry for not reducing the test case)
gcc-4.4 fails to compile some of my code, which compiled fine with (at least)
4.2 and 4.3. the preprocessed source is attached.
gcc version:
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../gcc-4.4-20081226/configure -v
--with-bugurl=file:/
--- Comment #24 from bonzini at gnu dot org 2008-12-30 10:39 ---
patch committed -- bug may be latent on 4.3, but there is no known testcase.
--
bonzini at gnu dot org changed:
What|Removed |Added
---
--- Comment #23 from bonzini at gnu dot org 2008-12-30 10:38 ---
Fixed. However, you should check if the code is valid C++ at all, because
out-of-range enum values are handled differently in C and C++ (the bug stemmed
from the fact that op was set to a value that is beyond what the C++
1 - 100 of 116 matches
Mail list logo
