--- Comment #5 from paulthomas2 at wanadoo dot fr 2006-10-11 06:11 ---
Subject: Re: LBOUND(TRANSPOSE(I)) doesn't work
FX,
That's because of F95 13.14.53:
Case (i): For an array section or for an array expression other than a whole
array or array structure component, LBOUND(ARRAY,
--- Comment #7 from gschafer at zip dot com dot au 2006-10-11 06:18 ---
The root cause of this bug is obvious after studying gcc.c. Essentially, the
user specified specs are read _way_ too late in the process. The sequence is
roughly this:
1 - search for default specs file, if found
program test
implicit none
type A
integer, allocatable :: j(:)
end type A
type(A):: x
x=f()
contains
function f()
type(A):: f
print *,I'm only called once in the fortran!
f = A((/1,2/))
end function f
end program
calls the function twice!
The code produced shows that
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-10-11 07:26
---
With the following patch:
Index: trans-array.c
===
--- trans-array.c (revision 117560)
+++ trans-array.c (working copy)
@@ -661,10
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-10-11 07:32
---
(In reply to comment #6)
Forget that patch, it's breaking lots of things :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29391
--- Comment #1 from bkoz at gcc dot gnu dot org 2006-10-11 07:55 ---
Mine.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #2 from bkoz at gcc dot gnu dot org 2006-10-11 07:56 ---
Note we don't actually know if this is a regression, as without the stricter
error checking that is now present this may not be failing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
--- Comment #3 from bkoz at gcc dot gnu dot org 2006-10-11 07:58 ---
This is probably just another ordering issue. I'm on it.
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
--- Comment #8 from paulthomas2 at wanadoo dot fr 2006-10-11 08:02 ---
Subject: Re: LBOUND(TRANSPOSE(I)) doesn't work
FX,
I get all intrinsics that work through temporaries working right:
Great!
So I only have PRODUCT, SUM, MATMUL, PACK and UNPACK to work on.
I wonder if
--- Comment #9 from bkoz at gcc dot gnu dot org 2006-10-11 08:30 ---
Subject: Bug 29095
Author: bkoz
Date: Wed Oct 11 08:30:42 2006
New Revision: 117629
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117629
Log:
2006-10-09 Benjamin Kosnik [EMAIL PROTECTED]
PR
--- Comment #10 from bkoz at gcc dot gnu dot org 2006-10-11 08:33 ---
Fixed in mainline and gcc-4.1.2.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from plessl at tik dot ee dot ethz dot ch 2006-10-11 08:44
---
I can confirm that this bug still exists on with avr-gcc (GCC) 4.0.2 (running
on Mac OS X 10.4.8/PPC, installed via Macports)
avr-gcc -Os ~/Documents/Downloads/usart.iusart.c: In function ‘UsartIOCtl’:
The code below works correctly when no Optimization flag is given to gcc and
process exits as soon as a SIGHUP is sent to it.
But if it is compiled with any one of -O flags, sending SIGHUP does not
terminate the process.
sig_atomic_t hup_rcvd = 0;
void hup_handler(int signo)
{
hup_rcvd =
--- Comment #4 from bkoz at gcc dot gnu dot org 2006-10-11 09:48 ---
This is a regression, oh well.
Can you confirm for me that mingw32 is a target w/o __cxa_atexit?
I don't suppose it will make any difference, but can you please try:
- __gnu_cxx::__recursive_mutex static_mutex;
+
--- Comment #5 from bkoz at gcc dot gnu dot org 2006-10-11 09:55 ---
Created an attachment (id=12407)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12407action=view)
simple failure testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
Hello,
I'me trying to build gcc4.1.1
with
gcc -v
gcc -v
Reading specs from
/logiciels/public/gcc-3.2.1/lib/gcc-lib/sparc-sun-solaris2.7/3.2.1/specs
Configured with: ../configure --with-local-prefix=/logiciels/public/gcc-3.2.1
--prefix=/logiciels/public/gcc-3.2.1 --enable-thread=posix
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-10-11 10:43
---
You need to put 'volatile' on hup_rcvd for this to work.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from patchapp at dberlin dot org 2006-10-11 10:45 ---
Subject: Bug number PR28230
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00607.html
--
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-10-11 10:53
---
This
../configure --with-mpfr=/logiciels/public/gmp-4.1.4/lib --enable-shared
--with-gnu-as=/logiciels/public/binutils-2.9/bin/as
--with-gnu-ld=/logiciels/public/binutils-2.9/bin/ld
and that
I thought it
--- Comment #1 from patchapp at dberlin dot org 2006-10-11 11:00 ---
Subject: Bug number PR29422
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00609.html
--
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-10-11 11:55 ---
Gimplification marks the TARGET_EXPR addressable in
{
__asm__ __volatile__(::m TARGET_EXPR D.1873, {
unsigned int __v;
unsigned int __v;
D.1873 = __v;
});
}
while it should mark the gimplified
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-10-11 12:23 ---
We're not folding
return (int) *((char *) (long unsigned int) i + a + 1B) + (int) *((char *)
(long unsigned int) i + b + 1B);
one reason is that the C frontend decomposes a[i], one is the array-to-pointer
decay
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-10-11 12:30 ---
One minimal fix for this is the following (patches for this I sent many times
long time ago, but poking in the C frontend is tedious):
Index: c-typeck.c
--- Comment #9 from bonzini at gnu dot org 2006-10-11 12:47 ---
For this, on i386-pc-linux-gnu, C and C++ give the exact (pessimized) same
code:
char a[10], b[10];
int f1(int i)
{
return a[i+1] + b[i+1];
}
That RTL address selection sucks is just a fact. :-)
--
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-10-11 12:53
---
I get (-O -m32) for C++:
_Z2f1i:
.LFB2:
pushl %ebp
.LCFI0:
movl%esp, %ebp
.LCFI1:
movl8(%ebp), %edx
addl$1, %edx
movsbl b(%edx),%eax
movsbl
--- Comment #11 from paolo dot bonzini at lu dot unisi dot ch 2006-10-11
13:05 ---
Subject: Re: [4.0/4.1/4.2 Regression] address selection does
not work correctly
movl8(%ebp), %edx
addl$1, %edx
movsbl b(%edx),%eax
movsbl a(%edx),%edx
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-11 13:12 ---
You need to look at preprocessed source. sig_atomic_t should have volatile
qualifier on it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29429
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-11 13:17
---
I'll note that the Portland, Intel and g95 compilers do not see this issue
either. SunStudio does, at runtime.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28849
--- Comment #6 from patchapp at dberlin dot org 2006-10-11 13:31 ---
Subject: Bug number PR29119
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00612.html
--
--- Comment #3 from anlauf at gmx dot de 2006-10-11 13:58 ---
(In reply to comment #2)
I'll note that the Portland, Intel and g95 compilers do not see this issue
either.
Well, I get a bounds violation with current versions of g95 (0.91)
on both Linux and Cygwin:
% g95 -g
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-10-11 14:03 ---
Fixed on the mainline.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-10-11 14:03 ---
Subject: Bug 29119
Author: rguenth
Date: Wed Oct 11 14:03:37 2006
New Revision: 117633
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117633
Log:
2006-10-11 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-11 14:28 ---
(In reply to comment #2)
You need to look at preprocessed source. sig_atomic_t should have volatile
qualifier on it.
It is not marked for glibc 2.4:
typedef int __sig_atomic_t;
typedef __sig_atomic_t
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-11 14:44 ---
http://www.codecomments.com/archive263-2005-8-441109.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29429
--- Comment #6 from bkoz at gcc dot gnu dot org 2006-10-11 14:48 ---
Created an attachment (id=12408)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12408action=view)
patch
Please try this and see if it works. If so, let me know.
-benjamin
--
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-11 14:55 ---
Subject: Bug 29002
Author: pinskia
Date: Wed Oct 11 14:55:07 2006
New Revision: 117635
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117635
Log:
2006-10-11 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-10-11 14:56 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from patchapp at dberlin dot org 2006-10-11 15:35 ---
Subject: Bug number PR27701
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00615.html
--
In fixing PR29373, I separated off the part to do with the function declaration
from that triggered by the constructor.
! { dg-do compile }
! Tests patch for PR29373, in which the implicit character
! statement messes up the function declaration because the
! requisite functions in decl.c were
--- Comment #19 from rguenth at gcc dot gnu dot org 2006-10-11 16:05
---
Subject: Bug 28230
Author: rguenth
Date: Wed Oct 11 16:05:37 2006
New Revision: 117637
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117637
Log:
2006-10-11 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-10-11 16:06
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from tobi at gcc dot gnu dot org 2006-10-11 16:07 ---
You're working too fast, Paul. Before I even got to read your answer you
already bring forward a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29373
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-11
16:30 ---
Subject: Re: FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90
and intrinsic_spacing.f90
--- Comment #1 from kargl at gcc dot gnu dot org 2006-10-10 22:34 ---
Update your source
The following code, when compiled using optimization (-O1, at least), produces
a segfault after several iterations of the loop. I have reproduced the bug on
two machines running the same OS and version of gcc:
$ gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs
Configured
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-11 16:47 ---
gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)
First, you should have reported it to redhat first.
Second I cannot reproduce this in 3.4.0, 4.0.0 or 4.1.0.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #3 from sgk at troutmask dot apl dot washington dot edu
2006-10-11 16:53 ---
Subject: Re: FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90
and intrinsic_spacing.f90
On Wed, Oct 11, 2006 at 04:30:20PM -, dave at hiauly1 dot hia dot nrc dot
ca wrote:
--- Comment #7 from patchapp at dberlin dot org 2006-10-11 17:00 ---
Subject: Bug number PR29373
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00620.html
--
--- Comment #8 from paulthomas2 at wanadoo dot fr 2006-10-11 17:05 ---
Subject: Re: implicit type declaration and contained function
clash
tobi at gcc dot gnu dot org wrote:
--- Comment #6 from tobi at gcc dot gnu dot org 2006-10-11 16:07 ---
You're working too fast, Paul.
--- Comment #13 from eweddington at cso dot atmel dot com 2006-10-11 17:05
---
(In reply to comment #12)
I can confirm that this bug still exists on with avr-gcc (GCC) 4.0.2 (running
on Mac OS X 10.4.8/PPC, installed via Macports)
snip
Is there any news on this bug?
Sorry, no.
--- Comment #14 from mi at aldan dot algebra dot com 2006-10-11 17:15
---
Ok, the problem is triggered by the ``-march=pentium4'' flag:
c++ -O0 -g -c -fno-strict-aliasing -pipe -march=pentium4 loctest.ii
[EMAIL PROTECTED]:source/test/intltest (1127) nm loctest.o | grep LC
U
--- Comment #2 from pault at gcc dot gnu dot org 2006-10-11 17:42 ---
Since I posted the patch, I had better take it unto myself!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-11
17:57 ---
Subject: Re: FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90
and intrinsic_spacing.f90
Done. The error still occurs. I don't see the symbol in any of the
library .o files.
Do
--- Comment #7 from echristo at apple dot com 2006-10-11 18:14 ---
I'm testing it now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
--- Comment #8 from echristo at apple dot com 2006-10-11 18:24 ---
OK. Seems to be working (i.e. build succeeded and testing isn't blowing up).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu
2006-10-11 18:30 ---
Subject: Re: FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90
and intrinsic_spacing.f90
Does youir OS have fabsf, frexpf, and ldexpf?
Yes, no, no. It has frexp and ldexp.
--- Comment #3 from dominiq at lps dot ens dot fr 2006-10-11 18:31 ---
Subject: Re: ICE with allocatable
Since I posted the patch, I had better take it unto myself!
Be my guest!-)
Dominique
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29422
Here is a code which doesn't compile. It takes all swap space (around 2GB) and
all system memory(about 1GB), compiles around 15-20 minutes and then crashes
with the following message : g++: Internal error: Killed (program cc1plus)
--
Summary: Internal error while compiling code using
--- Comment #1 from grayyoga at gmail dot com 2006-10-11 19:10 ---
Created an attachment (id=12409)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12409action=view)
preprocessed source file
This is output of the compiler with the -save-temps switch. It's compressed
'cause there is
--- Comment #9 from bkoz at gcc dot gnu dot org 2006-10-11 19:11 ---
Hmm. Eric, are you testing this on mingw32, or on darwin? If darwin, is this
the cause of the recent massive failures?
If so, I'll put this in immediately. If you can let me know in the next 2-3
hours I can get it in
The following code (derived from alloc_comp_constructor_1.f90):
! { dg-do run }
! { dg-options -fdump-tree-original }
! Test constructors of derived type with allocatable components (PR 20541).
!
! Contributed by Erik Edelmann [EMAIL PROTECTED]
!and Paul Thomas [EMAIL PROTECTED]
!
--- Comment #2 from grayyoga at gmail dot com 2006-10-11 19:13 ---
Created an attachment (id=12410)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12410action=view)
gcc -V output
version and configuration information on the used gcc.
--
--- Comment #3 from grayyoga at gmail dot com 2006-10-11 19:14 ---
Created an attachment (id=12411)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12411action=view)
Command Line and Error Message
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-10-11 19:31
---
Subject: Bug 29024
Author: lmillward
Date: Wed Oct 11 19:31:33 2006
New Revision: 117641
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117641
Log:
PR c++/29024
* cp-tree (struct
--- Comment #10 from echristo at apple dot com 2006-10-11 19:34 ---
Testing on darwin, the patch seems to get rid of the massive failures I was
seeing.
Thanks Ben.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29426
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-11 19:36 ---
This takes 79% of my 2GB of memory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
--- Comment #15 from mi at aldan dot algebra dot com 2006-10-11 19:38
---
Removing either the line 16037 or the 15167 in the loctest.ii gets rid of the
problem.
The lines both reference a string literal (en_GB_EURO), thus the bug, likely,
has something to do with how the identical
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-10-11 19:43
---
Fixed on mainline.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from bkoz at gcc dot gnu dot org 2006-10-11 20:18 ---
Subject: Bug 29426
Author: bkoz
Date: Wed Oct 11 20:18:36 2006
New Revision: 117643
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117643
Log:
2006-10-11 Benjamin Kosnik [EMAIL PROTECTED]
PR
--- Comment #2 from pault at gcc dot gnu dot org 2006-10-11 20:43 ---
Created an attachment (id=12412)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12412action=view)
The correct fix for this PR
THis turns out to be completely specific to nullify, or to a pointer assign to
NULL().
--- Comment #12 from dannysmith at users dot sourceforge dot net
2006-10-11 20:54 ---
(In reply to comment #4)
- __gnu_cxx::__recursive_mutex static_mutex;
+ static __gnu_cxx::__recursive_mutex static_mutex;
I tried thaty before I submitted bug report. No dice.
(In reply to
--- Comment #28 from tromey at gcc dot gnu dot org 2006-10-11 21:06 ---
I doubt those configure warnings are very important.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-11
21:45 ---
Subject: Re: FAIL: gfortran.fortran-torture/execute/intrinsic_rrspacing.f90
and intrinsic_spacing.f90
Do you have scalbnf?
No. Just scalbn.
Dave
--
--- Comment #7 from laurent at guerby dot net 2006-10-11 21:53 ---
Confirmed.
$ gcc -c -gnat05 ada_3d-file_io-step_reader.adb
+===GNAT BUG DETECTED==+
| 4.2.0 20060922 (experimental) (x86_64-unknown-linux-gnu) Assert_Failure
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-10-11 21:56 ---
Confirmed. Uses a lot of memory.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from brooks at gcc dot gnu dot org 2006-10-11 22:00 ---
As per discussion on the fortran@ mailing list, the answer returned by gfortran
and ifort (namely, that LBOUND(x%a) is the same as LBOUND(y)) is
standard-conforming, and g95 is in error.
--
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-10-11 22:04
---
This is fixed now. Or was invalid.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from mmitchel at gcc dot gnu dot org 2006-10-11 22:30
---
This patch is OK, thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28709
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
I get a segmentation fault compiling the attached testcase with gcc 4.1. 4.0
and 4.2 seem to work. 4.1.2 20060901 (Debian 4.1.1-13) also worked but
4.1.2 20061007 (Debian 4.1.1-16) fails, at least on x86_64.
(sid)1142:[EMAIL PROTECTED]: ~] g++-4.1 -c cinepaint-plugin_main.cpp
--- Comment #1 from tbm at cyrius dot com 2006-10-11 23:01 ---
Created an attachment (id=12413)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12413action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29435
--- Comment #2 from tbm at cyrius dot com 2006-10-11 23:02 ---
Ignore my comment about x86_64. I also see this on mips.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29435
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-11 23:05 ---
I think this is a sizeof issue:
sizeof (Rgb XYindex )
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29435
--- Comment #4 from tbm at cyrius dot com 2006-10-11 23:19 ---
(gdb) where
#0 0x0045a5ce in cxx_sizeof_or_alignof_type (type=0x2b29cf3e6b00,
op=214, complain=1 '\001')
at /home/tbm/scratch/gcc-4.1/gcc/cp/typeck.c:1251
#1 0x0044a947 in cp_parser_unary_expression
--- Comment #2 from brooks at gcc dot gnu dot org 2006-10-12 00:07 ---
On a similar note, the following is legal code for which an error is
incorrectly reported:
$ cat pr20863a.f90
PURE FUNCTION give_next(i)
TYPE node_type
sequence
TYPE(node_type), POINTER ::
--- Comment #3 from patchapp at dberlin dot org 2006-10-12 00:15 ---
Subject: Bug number PR29371
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00635.html
--
--- Comment #7 from debian-gcc at lists dot debian dot org 2006-10-12
00:37 ---
fails with trunk 20061012 as well.
Matthias
--
debian-gcc at lists dot debian dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2006-10-12 00:39 ---
int array3[(const unsigned short) (20.5 * 3)];
error message from compiler is:
error: array bound is not an integer constant
to me this is wrong because the expression (const unsigned short) (20.5 * 3)
is an
--- Comment #3 from bangerth at dealii dot org 2006-10-12 00:41 ---
Confirmed.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC|
$ cat ice.c
typedef struct S {
unsigned long flags;
}S_t;
struct dp {
S_t c;
};
typedef S_t __attribute__((__may_alias__)) cmonkey;
static void handler(void *vp)
{
struct dp *dp;
cmonkey *cm = vp;
dp-c = *cm;
}
$ gcc -m32 -std=gnu99 -W -Wall -g3 -c ice.c
--- Comment #2 from bangerth at dealii dot org 2006-10-12 00:56 ---
Why exactly do you think that the empty base should not be located at
the same address as the simple_base base object?
W.
--
bangerth at dealii dot org changed:
What|Removed
--- Comment #4 from bangerth at dealii dot org 2006-10-12 01:03 ---
The operator== you want to call is used in a context in which the
template argument cannot be deduced (a non-deduceable context).
If you want to use this construct, you will have to write something like
--- Comment #19 from bangerth at dealii dot org 2006-10-12 01:06 ---
Since this is solved on mainline and nobody seems to have been able to
ever reproduce it anyway, there doesn't seem to be a chance of this
being actively worked on on older release branches. I'll therefore close
it. We
--
bangerth at dealii dot org changed:
What|Removed |Added
Known to work||4.2.0
Target Milestone|4.1.2 |4.2.0
--- Comment #2 from bangerth at dealii dot org 2006-10-12 01:08 ---
What exactly is the problem here? I get this as an error message:
g/x /home/bangerth/bin/gcc-4.2-pre/bin/c++ -c x.cc
x.cc: In function #8216;void f()#8217;:
x.cc:3: error: break statement not within loop or switch
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-12 01:12 ---
(In reply to comment #2)
What exactly is the problem here? I get this as an error message:
g/x /home/bangerth/bin/gcc-4.2-pre/bin/c++ -c x.cc
x.cc: In function #8216;void f()#8217;:
x.cc:3: error: break
--- Comment #1 from acahalan at gmail dot com 2006-10-12 01:20 ---
Other ways to ICE gcc:
///
typedef struct S {
unsigned long flags;
}S_t;
typedef S_t __attribute__((__may_alias__)) cmonkey;
S_t *handler(void *vp)
{
cmonkey *cm = vp;
return
--- Comment #4 from bangerth at math dot tamu dot edu 2006-10-12 01:25
---
Subject: Re: bad break/continue is not dectected until the
gimplifier
Yes but this semantics anyalsis is done while gimplifing and not while
parsing.
But I get the message also when using
--- Comment #2 from acahalan at gmail dot com 2006-10-12 01:25 ---
Hey, I don't even need to use the types. The typedef alone
is enough to ICE gcc:
typedef struct S {
unsigned long flags;
}S_t;
typedef S_t __attribute__((__may_alias__)) cmonkey;
int main(int argc, char
[decl.init.ref]/5 has the following text for initialization of
constant references with rvalues:
5 A reference to type cv1 T1 is initialized by an expression of type
cv2 T2 as follows:
[...]
-- If the initializer expression is an rvalue, with T2 a class
type, and cv1 T1 is
--- Comment #1 from bangerth at dealii dot org 2006-10-12 01:39 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
1 - 100 of 125 matches
Mail list logo
