[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #24 from gdr at integrable-solutions dot net 2006-10-24 06:53 --- Subject: Re: [4.0/4.1/4.2 Regression] placement new does not change the dynamic type as it should "mark at codesourcery dot com" <[EMAIL PROTECTED]> writes: | --- Comment #22 from mark at codesourcery d

Re: [Bug libstdc++/29286] [4.0/4.1/4.2 Regression] placement new does not change the dynamic type as it should

"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes: | --- Comment #22 from mark at codesourcery dot com 2006-10-04 05:39 --- | Subject: Re: [4.0/4.1/4.2 Regression] placement new | does not change the dynamic type as it should | | ian at airs dot com wrote: | > --- Comment

[Bug c++/29455] Issues with -Wchar-subscripts

--- Comment #6 from gdr at integrable-solutions dot net 2006-10-24 06:32 --- Subject: Re: New: Issues with -Wchar-subscripts "h dot b dot furuseth at usit dot uio dot no" <[EMAIL PROTECTED]> writes: | [This is both a C and C++ bug report, not sure how to classify that.] | | int a[2

[Bug libstdc++/25608] g++ miscompiles gcjx

--- Comment #21 from gdr at integrable-solutions dot net 2006-10-24 06:18 --- Subject: Re: g++ miscompiles gcjx "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | Gaby, any news about this issue? gcjx has been declared dead. I never got to have the issue fixed. So, it is up to

[Bug c++/29020] [4.0 regression] ICE using A::A instead of A in friend declaration

--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-10-24 04:06 --- Volker -- Thank you for spotting this. I decided not to backport the friend.c changes because the new asserts might somehow cause a problem. However, I have now added the testcase, after verifying that it passed

[Bug c++/29020] [4.0 regression] ICE using A::A instead of A in friend declaration

--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-10-24 03:58 --- Subject: Bug 29020 Author: mmitchel Date: Tue Oct 24 03:58:40 2006 New Revision: 117994 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117994 Log: PR c++/29020 * g++.dg/template/friend48.C:

[Bug c++/29577] overload/SFINAE problem

--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-24 02:30 --- Oh, I read the bug incorrectly. As I understand it 0 is special as it is also the NULL pointer and you don't need a cast for it to assign a pointer to it. Maybe we forget to take that into account. -- http://gc

[Bug c++/29577] overload/SFINAE problem

--- Comment #2 from bangerth at dealii dot org 2006-10-24 02:21 --- I'm not completely sure who's right and wrong, but here's what's happening: the second argument in the X case is an integer (the number zero), not an int*. Consequently, the first template is not an exact match, but requ

[Bug fortran/29563] Internal read loses data.

--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-10-24 02:12 --- I will have to investigate. If you initialize the array tmpbox to something other than 0 you will see that the list read is not reading the 9th value at all. -- jvdelisle at gcc dot gnu dot org changed:

[Bug c++/29577] overload/SFINAE problem

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-24 00:56 --- This code compiles for me with 4.2.0 and 4.0.2. As I understand this, in the Y case the first template overload gets rejected as X::T does not exist. In the X case, the first template is an exact match so it matches

[Bug c++/29577] New: overload/SFINAE problem

The following code reports that neither class X nor Y contain nexted class T: #include #include struct X { typedef int T; }; class Y{ }; template void foo(Z const& z, typename Z::T* p) { std::cout << "has Z::T" << std::endl; } template void foo(Z const& z, ...) { std::cout << "hasn't Z::T"

[Bug tree-optimization/14784] [Tree-ssa] alias analysis deficiency

--- Comment #7 from rakdver at gcc dot gnu dot org 2006-10-24 00:12 --- Subject: Bug 14784 Author: rakdver Date: Tue Oct 24 00:12:16 2006 New Revision: 117986 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117986 Log: PR tree-optimization/14784 * tree-flow.h (str

[Bug tree-optimization/29543] Poor code generated for arrays with variable bounds

--- Comment #14 from jeff at thecreems dot com 2006-10-23 23:50 --- (In reply to comment #1) > Created an attachment (id=12473) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12473&action=view) [edit] > Source code and very simple build script for Ada and FORTRAN code capable of > s

[Bug bootstrap/29544] [4.2 Regression] Not building with checking in stage1

--- Comment #6 from bonzini at gnu dot org 2006-10-23 22:41 --- ok, mine then. -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc

[Bug preprocessor/11242] [mingw32] #include takes my memory directory instead of the standard memory header file

--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-23 22:32 --- Confirmed. (In reply to comment #3) > Reopening since this is still an issue. Though only on mingw32. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug c++/11242] #include takes my memory directory instead of the standard memory header file

--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-23 22:31 --- Reopening since this is still an issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug fortran/22282] loc intrinsic and %loc construction is not implemented in gfortran

--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-23 22:04 --- *** Bug 29575 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug fortran/29575] gfortran missing %LOC intrinsic for g77 compatibility

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-23 22:04 --- *** This bug has been marked as a duplicate of 22282 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

[Bug fortran/22282] loc intrinsic and %loc construction is not implemented in gfortran

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22282

[Bug fortran/22282] loc intrinsic and %loc construction is not implemented in gfortran

--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-23 22:03 --- Reopening since %loc was not added even though it should be easy to add now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/29575] New: gfortran missing %LOC intrinsic for g77 compatibility

Although we have had the LOC intrinsic in place since the cray pointer patch was merged... http://mail.la.utexas.edu/lab/software/devtool/gnu/g77/g77_243.html#SEC273 , we still don't have support for the g77 %LOC intrinsic... http://mail.la.utexas.edu/lab/software/devtool/gnu/g77/g77_56.html -

[Bug fortran/29550] Optimize -fexternal-blas calls for conjg()

--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-23 21:56 --- (In reply to comment #2) > We could detect in iresolve.c (gfc_resolve_matmul) that one (or both) of the > arguments to MATMUL is a call to CONJ, and then rewrite the code to be > MATMUL(A,B,2) instead of MATMUL(A,

[Bug middle-end/29574] Gcc gives invalid warning about unitialized variable

--- Comment #9 from pinskia at earth dot geop dot uc dot edu 2006-10-23 21:52 --- Subject: Re: Gcc gives invalid warning about unitialized variable > > > > --- Comment #8 from mbligh at mbligh dot org 2006-10-23 21:50 --- > > Initialize the variable and forget about ineffi

Re: [Bug middle-end/29574] Gcc gives invalid warning about unitialized variable

> > > > --- Comment #8 from mbligh at mbligh dot org 2006-10-23 21:50 --- > > Initialize the variable and forget about inefficiency. Again this is fixed > > for > > 4.2.0, the warning is only because __builtin_expect gets in the way of > > figuring > > out if the variable is used uni

[Bug middle-end/29574] Gcc gives invalid warning about unitialized variable

--- Comment #8 from mbligh at mbligh dot org 2006-10-23 21:50 --- > Initialize the variable and forget about inefficiency. Again this is fixed > for > 4.2.0, the warning is only because __builtin_expect gets in the way of > figuring > out if the variable is used uninitialized, nothing

[Bug middle-end/29574] Gcc gives invalid warning about unitialized variable

--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-23 21:45 --- (In reply to comment #6) > Re the non-inlined functions ... > Have been discussing this with Andrew Morton. > > what do we do then? Adding dead code to fix the fact that gcc can't see into > other functions is incor

[Bug middle-end/29574] Gcc gives invalid warning about unitialized variable

--- Comment #6 from mbligh at mbligh dot org 2006-10-23 21:42 --- Re the non-inlined functions ... Have been discussing this with Andrew Morton. what do we do then? Adding dead code to fix the fact that gcc can't see into other functions is incorrect and inefficient. Having lots of com

[Bug tree-optimization/29567] [4.3 regression] ICE in build2_stat, at tree.c:2963

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org

[Bug tree-optimization/29567] [4.3 regression] ICE in build2_stat, at tree.c:2963

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- |

[Bug middle-end/29478] [4.2 Regression] optmization generates warning for casts

--- Comment #8 from pinskia at gmail dot com 2006-10-23 21:37 --- Subject: Re: [4.2 Regression] optmization generates warning for casts On 23 Oct 2006 17:30:22 -, amylaar at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > I think it is wrong that we are optimizing the expression b

[Bug middle-end/29574] Gcc gives invalid warning about unitialized variable

--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-23 21:30 --- (In reply to comment #4) > And indeed, if I remove that unlikely(), it does work. > > There's another set of these where the called initializer is not inlined, > ie: > > int x; > initializer(&x); If initializer is

[Bug tree-optimization/21513] [4.0/4.1/4.2 Regression] __builtin_expect getting in the way of uninitialized warnings

--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-23 21:30 --- *** Bug 29574 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug middle-end/29574] Gcc gives invalid warning about unitialized variable

--- Comment #4 from mbligh at mbligh dot org 2006-10-23 21:19 --- And indeed, if I remove that unlikely(), it does work. There's another set of these where the called initializer is not inlined, ie: int x; initializer(&x); Which it seems totally blind to, even if the initializer does

[Bug middle-end/29574] Gcc gives invalid warning about unitialized variable

--- Comment #3 from mbligh at mbligh dot org 2006-10-23 21:08 --- Yeah, is builtin_expect ;-( #define likely(x) __builtin_expect(!!(x), 1) #define unlikely(x) __builtin_expect(!!(x), 0) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29574

[Bug middle-end/29574] Gcc gives invalid warning about unitialized variable

--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-23 20:59 --- If it is defined using __builtin_expect, then this is most likely PR 21513 which was fixed for 4.2.0, it is hard to fix correctly for 4.1.0 and 4.0.0 without removing all of loop.c. Can you attach the preprocessed s

[Bug middle-end/29574] Gcc gives invalid warning about unitialized variable

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-23 20:57 --- How is unlikely defined? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29574

[Bug preprocessor/28709] [4.0/4.1 regression] Bad diagnostic pasting tokens with ##

--- Comment #3 from reichelt at gcc dot gnu dot org 2006-10-23 20:41 --- Just a minor nit: The second error message still contains the "->" token which should not have been generated. But that's probably tolerable. bug.c:2:1: error: pasting "-" and ">>" does not give a valid preprocess

[Bug c/29574] New: Gcc gives invalid warning about unitialized variable

Compile Linux 2.6.18 kernel. Warns that idx may be uninitialized in fs/bio.c:bio_alloc_bioset(), but it clearly *is* being initialized by bvec_alloc_bs. The kernel team will not allow us to pre-initialize these, as it is a gcc bug. On the other hand, we're drowned in invalid warnings, so can't se

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time

--- Comment #13 from ghazi at gcc dot gnu dot org 2006-10-23 20:25 --- Subject: Bug 29335 Author: ghazi Date: Mon Oct 23 20:24:55 2006 New Revision: 117983 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117983 Log: PR middle-end/29335 * builtins.c (fold_builtin_s

[Bug c++/29573] [4.0/4.1/4.2/4.3 regression] ICE after parse error in template argument

-- 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=29573

[Bug c++/29573] New: [4.0/4.1/4.2/4.3 regression] ICE after parse error in template argument

The following invalid code snippet triggers a segfault since GCC 3.4.0: == template struct A {}; template struct B : A {}; template struct C : A {}; == bug.cc:3: error: parse error in template argu

[Bug c++/29571] [4.2/4.3 regression] ICE with invalid static const member

-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29571

[Bug fortran/29572] New: Bounds check should check size of array: d(1:1,1:1) = a(1:4,1:4)

In the following one assignes a 4x4 array to a 1x1 array. (Reason: transpose() at the wrong place.) Expected: This is detected at run time using -fbounds-check Current result: Crash. program mat implicit none complex, allocatable :: a(:,:),b(:,:) complex :: d(1,1) allocate(a(

[Bug c++/29571] New: [4.2/4.3 regression] ICE with invalid static const member

The following invalid code snippet triggers an ICE on mainline and 4.3 branch: == struct A { static const int i = 0/0 + ""; static const int j = int(i); }; == bug.cc:3: warning: division by zero in '0 / 0' bug.cc:3: error

[Bug c++/29570] [4.1/4.2/4.2 regression] ICE with brace-enclosed initializer

-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.2 4.2.0 4.3.0 Known to work||4.

[Bug c++/29570] New: [4.1/4.2/4.2 regression] ICE with brace-enclosed initializer

The following valid code snippet triggers a segfault on mainline, 4.1 branch, and 4.0 branch. The regression is recent, since GCC 4.1.1 is not affected. template struct A { static const int i; }; template const int A::i = { A::i };

[Bug middle-end/29567] [4.3 regression] ICE in build2_stat, at tree.c:2963

--- Comment #2 from martin at mpa-garching dot mpg dot de 2006-10-23 19:50 --- (In reply to comment #1) > Can you try the patch in: > http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01168.html > ? Yes, this patch fixes the problem. Thanks for the prompt reply! -- http://gcc.gnu.org/b

[Bug libfortran/29568] implement unformatted files with subrecords (Intel style)

--- Comment #1 from kargl at gcc dot gnu dot org 2006-10-23 19:49 --- Thomas, Have you written Adrain about his plans concerning his patch? BTW, I think the Intel subrecord approach is probably the best solution to the large record problem. -- http://gcc.gnu.org/bugzilla/show_bug.

[Bug fortran/18026] boz initialization of REALs fails

--- Comment #13 from sgk at troutmask dot apl dot washington dot edu 2006-10-23 19:39 --- Subject: Re: boz initialization of REALs fails On Mon, Oct 23, 2006 at 06:52:06PM -, tobias dot burnus at physik dot fu-berlin dot de wrote: > > In the Intel Fortran Compiler > real :: r >

[Bug c++/29020] [4.0 regression] ICE using A::A instead of A in friend declaration

--- Comment #5 from reichelt at gcc dot gnu dot org 2006-10-23 19:32 --- Mark, you accidentally committed the fix in parser.c with your patch for PR 28506 (rev. 117695) to the 4.1 branch: http://gcc.gnu.org/ml/gcc-cvs/2006-10/msg00361.html So this is now fixed on the 4.1 branch, too.

[Bug fortran/25080] ICE/missing error on different ranks for dummy and actual arguments

--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-23 19:28 --- We now reject the reporter's code as we should. We could still reject the code in comment #1, but none of the other compilers I tried reject it. Marking this as low priority (I think it will be fixed by Paul Thoma

[Bug c/29569] use function name as operand in asm inline statement

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-23 19:27 --- This works for me in 3.0.4 to 3.4.0 and now errors out in 4.0.0 and above with: t.c:5: error: memory input 1 is not directly addressable -- pinskia at gcc dot gnu dot org changed: What|Removed

[Bug target/27891] [4.0/4.1 regression] ICE in tree_split_edge, at tree-cfg.c:3107

--- Comment #4 from janis at gcc dot gnu dot org 2006-10-23 19:16 --- A regression hunt using the testcase from comment #2 with -O2 using an alpha-linux cross compiler identified this patch which fixed the ICE on mainline: http://gcc.gnu.org/viewcvs?view=rev&rev=110556 r110556

[Bug c++/28255] [4.1 regression] ICE with (GNU extension) C99 compund literal (scalar), initializer and templates

--- Comment #8 from reichelt at gcc dot gnu dot org 2006-10-23 19:11 --- As Andrew already noted, this is not fixed on the 4.1 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added

[Bug other/29524] Too much RAM used: __clz_tab[] linked

--- Comment #4 from batt at develer dot com 2006-10-23 19:09 --- I have 3 projects involving gcc and avr, and all of these have an increased RAM usage due to __clz_tab linking after switching from gcc 4.1.1 to 4.2. I will try as soon as possible to find a suitable testcase. -- http:

[Bug fortran/17872] gfortran accepts 255_1 as integer constant

--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-23 19:07 --- Fixed on 4.2 branch and probably earlier: In file a.f90:1 integer*1 :: i1 = 255_1 1 Error: Integer too big for its kind at (1) In file a.f90:2 integer*2 :: i2 = 65535_2

[Bug fortran/24828] Z and negative integers

--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-23 19:05 --- (In reply to comment #4) > Can this PR be closed? I'd say yes. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added

[Bug target/26510] [4.1/4.2 Regression] --disable-shared broken for darwin platform

--- Comment #6 from dir at lanl dot gov 2006-10-23 19:02 --- I tried to disable the multilib with - ../gcc/configure --disable-shared --disable-multilib --prefix=/usr/local/gfortran --enable-languages=c,fortran but I still about the save errors - MLIBS=`/Users/dir/gfortran/ibin2/./gcc

[Bug c/29569] New: use function name as operand in asm inline statement

(stevenhu) / [159] > cat a.c void func(){} main(){ int a,b; /*asm(" %ecx %eax");*/ asm("add %0,%1,%2":"=r"(a):"m"(func),"m"(b)); } (stevenhu) / [160] > gcc -S a.c a.c: In function `main': a.c:6: Internal compiler error in instantiate_virtual_regs_1, at function.c:3972 Please submit a full bug r

[Bug fortran/18026] boz initialization of REALs fails

--- Comment #12 from tobias dot burnus at physik dot fu-berlin dot de 2006-10-23 18:52 --- Cf. also bug 29471. In the Intel Fortran Compiler real :: r data r/some BOZ/ gives the same result as using the Fortran 2003 statement in ifort: real :: r r = real(some boz) (At least with th

[Bug libfortran/29568] New: implement unformatted files with subrecords (Intel style)

There's an on-off discussion on the gfortran mailing list on making 4-byte record markers the default for gfortran. This would only be acceptable if large (>2 GB) records could be written that way. I'm taking a shot at this. -- Summary: implement unformatted files with subrecords (In

[Bug fortran/29567] [4.3 regression] ICE in build2_stat, at tree.c:2963

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-23 18:13 --- Can you try the patch in: http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01168.html ? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug fortran/29567] [4.3 regression] ICE in build2_stat, at tree.c:2963

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot |

[Bug fortran/29567] New: [gfortran, 4.3 regression] ICE in build2_stat, at tree.c:2963

ad model: posix gcc version 4.3.0 20061023 (experimental) /home/martin/software/ugcc/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/f951 test.f90 -quiet -dumpbase test.f90 -mtune=generic -auxbase test -O2 -version -I /home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/finclude -o /tmp/ccs

[Bug middle-end/29478] [4.2 Regression] optmization generates warning for casts

--- Comment #7 from amylaar at gcc dot gnu dot org 2006-10-23 17:30 --- (In reply to comment #6) > A regression hunt identified the following patch: > > http://gcc.gnu.org/viewcvs?view=rev&rev=116424 > > r116424 | amylaar | 2006-08-25 18:51:57 + (Fri, 25 Aug 2006) > When

[Bug fortran/29565] [4.1/4.2 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c

--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-23 17:11 --- Further reduced testcase, confirmed on ppc-darwin: type element_t integer :: gid end type element_t type(element_t) :: element(1) call hash_read_key(element%gid) call hash_read_key(element%gid)

[Bug fortran/18026] boz initialization of REALs fails

--- Comment #11 from kargl at gcc dot gnu dot org 2006-10-23 17:10 --- *** Bug 29561 has been marked as a duplicate of this bug. *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added --

[Bug fortran/29561] hexadecimal constant problem

--- Comment #2 from kargl at gcc dot gnu dot org 2006-10-23 17:10 --- Please the audit trail for Pr 18026. It gives the details. Also, the difference in the earlier version of gfortran to the newer version is due to this patch. 2006-09-07 Steven G. Kargl <[EMAIL PROTECTED]>

[Bug libstdc++/24025] libstdc++ crashes when out of memory exception thrown

--- Comment #9 from pcarlini at suse dot de 2006-10-23 16:26 --- The issue seems more tricky, even for TLS platforms, see: http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00333.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24025

[Bug debug/29558] [4.2 Regression] ICE in set_variable_part, at var-tracking.c:2140

--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-23 16:06 --- It works for me with 4.1.2 20061017 but fails with 4.2.0 20061015 so this only fails on the 4.2 branch. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug fortran/29565] [4.1/4.2 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.c

--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-23 15:58 --- Confirmed, reduced testcase: module hash_mod type element_t integer :: gid end type element_t type grid_type type(element_t), pointer :: element(:) end type grid_type contains subroutine hash_read_key(key) inte

[Bug fortran/29563] Internal read loses data.

--- Comment #1 from pault at gcc dot gnu dot org 2006-10-23 15:54 --- program gfbread character(len=256), dimension(3) :: block_data = (/' 1 2 3',' 4 5 6',' 7 8 9'/) real(kind=8), dimension(3,3) :: tmp_box read(block_data,'(3(3f2.0/))',iostat=iostat)((tmp_box(i,j),j=1,3

[Bug fortran/29565] ICE in gimplify_var_or_parm_decl, at gimplify.c

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29565

[Bug fortran/29565] ICE in gimplify_var_or_parm_decl, at gimplify.c

--- Comment #2 from william dot mitchell at nist dot gov 2006-10-23 15:49 --- This is on Linux Fedora Core 1 with a Linux binary download of gfortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29565

[Bug middle-end/29558] [4.2 Regression] ICE in set_variable_part, at var-tracking.c:2140

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot |

[Bug fortran/29565] ICE in gimplify_var_or_parm_decl, at gimplify.c

--- Comment #1 from william dot mitchell at nist dot gov 2006-10-23 15:47 --- Created an attachment (id=12481) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12481&action=view) this is the program that demonstrates the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29565

[Bug fortran/29565] New: ICE in gimplify_var_or_parm_decl, at gimplify.c

ortran --version GNU Fortran 95 (GCC) 4.3.0 20061023 (experimental) -- Summary: ICE in gimplify_var_or_parm_decl, at gimplify.c Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: critical Priority: P3 Co

[Bug bootstrap/29544] [4.2 Regression] Not building with checking in stage1

--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-23 15:44 --- (In reply to comment #4) > Like this? Actually thinking about it some more, that will cause stage1 not to be build with the more checking if the user wanted it to be, ie --enable-checking=yes,rtl,gcac when configurin

[Bug bootstrap/19176] [4.0/4.1/4.2 Regression] static gcc cannot be build (libgcc_eh.a required for static gcc)

--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-23 15:26 --- Caused by: 2004-11-03 Andrew Pinski <[EMAIL PROTECTED]> * config/darwin.h (REAL_LIBGCC_SPEC): Define to use shared libgcc for shared libraries. -- pinskia at gcc dot gnu dot org changed:

[Bug target/26510] [4.1/4.2 Regression] --disable-shared broken for darwin platform

--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-23 15:24 --- Caused by: 2005-09-28 Geoffrey Keating <[EMAIL PROTECTED]> * config/rs6000/t-darwin8: Uncomment contents, allow -m64 multilib to be built. * Makefile.in: Export LIPO_FOR_TARGET, STRIP_FOR_

[Bug bootstrap/26510] --disable-shared broken for darwin platform

--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-23 15:22 --- *** Bug 29564 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug fortran/29564] build of gfortran with "--disable-shared" fails

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-23 15:22 --- *** This bug has been marked as a duplicate of 26510 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

[Bug fortran/29562] -malign-double breaks formatted IO

--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-23 15:19 --- This is not a bug, -malign-double changes the ABI. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

[Bug middle-end/29519] [4.2 Regression] Bad code on MIPS with -fnon-call-exceptions

--- Comment #8 from daney at gcc dot gnu dot org 2006-10-23 15:00 --- The patch is here: http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01149.html -- daney at gcc dot gnu dot org changed: What|Removed |Added --

[Bug boehm-gc/25652] Java support for amd64-pc-freebsd

--- Comment #6 from arno at heho dot snv dot jussieu dot fr 2006-10-23 14:58 --- Created an attachment (id=12480) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12480&action=view) Take III Most of the original patch probably has been commited when adding support for GNU/kFreeBSD.

[Bug debug/27017] [4.0/4.1/4.2 Regression] Debug information for static local class members are not emitted

--- Comment #9 from drow at gcc dot gnu dot org 2006-10-23 14:15 --- I haven't had another chance to work on this; update assigned to reflect reality. Hopefully the analysis will be useful to someone. -- drow at gcc dot gnu dot org changed: What|Removed

[Bug fortran/29564] New: build of gfortran with "--disable-shared" fails

I want to build gfortran with "--disable-shared" so that I can give fortran programs created with gfortran to people who need to use the programs, but do not have gfortran installed. I configured with - ../gcc/configure --disable-shared --prefix=/usr/local/gfortran --enable-languages=c,fortran a

[Bug fortran/29563] New: Internal read loses data.

gcc version 4.3.0 20061023 (experimental) Mandriva 2006.0 The program program gfbread character(len=256), dimension(3) :: block_data = (/'1 2 3','4 5 6','7 8 9'/) real(kind=8), dimension(3,3) :: tmp_box read(block_data,*,iostat=iostat)((tmp_box

[Bug fortran/29562] -malign-double breaks formatted IO

/gfortran_nightbuild/irun-20061023 --enable-languages=c,fortran --with-gmp=/home/fxcoudert/gfortran_nightbuild/software Thread model: posix gcc version 4.3.0 20061023 (experimental) The O/S is Mandriva 2006. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29562

[Bug fortran/29562] -malign-double breaks formatted IO

--- Comment #2 from refson dot temp at ntlworld dot com 2006-10-23 13:46 --- Sorry. This is on a 32-bit AMD Athlon 1800+ processor. I assume the issue doesn't arise on 64-bit hardware. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29562

[Bug fortran/29562] -malign-double breaks formatted IO

--- Comment #1 from pault at gcc dot gnu dot org 2006-10-23 13:02 --- Keith, You do not report your hardware/OS/gfortran version - your testcase works for me on amd64/SUSE10.1 or Cygwin_NT/gcc-4.3 Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29562

[Bug fortran/29562] New: -malign-double breaks formatted IO

The program program gftest write(*,'(a)') 'Hello World' end program gftest generates the erroneous error report At line 3 of file gftest.f90 Fortran runtime error: Missing initial left parenthesis in format Äø when compiled with the "-malign-double" flag. In a larger pro

[Bug target/29347] i386 mode switching clobbers fp exception handling bits

--- Comment #4 from amylaar at gcc dot gnu dot org 2006-10-23 12:10 --- (In reply to comment #3) > Can you provide a testcase where something goes wrong? > I was merely documenting a problem that I found while reading the code; I don't have time to write a testcase now. -- http://

[Bug fortran/29561] hexadecimal constant problem

--- Comment #1 from kloedej at knmi dot nl 2006-10-23 12:03 --- Sorry, variable names should differ of course, the sample code should be: program testhexconstant integer, parameter :: i4_ = Selected_Int_Kind( 9) ! works fine integer(i4_), parameter :: a = z"7F81" ! trigge

[Bug c++/29535] [4.1/4.2 Regression] ICE in instantiate_class_template, at cp/pt.c:5728

--- Comment #6 from rguenth at gcc dot gnu dot org 2006-10-23 11:58 --- Note this is a regression on the 4.1 branch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/29561] New: hexadecimal constant problem

exconstant triggers this error: gfortran -o testhex TestHex.F90 In file TestHex.F90:8 integer(i4_), parameter :: b = z"FF81" 1 Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1) for the gfortran version download

[Bug other/29559] '-O1 -ftree-vrp -fwrapv' misscompiles stable gnupg-1.4.5.

--- Comment #3 from pluto at agmk dot net 2006-10-23 11:51 --- (In reply to comment #2) > Testcase? ;) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.5.tar.bz2 ;) working on reduced version... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29559

[Bug other/29559] '-O1 -ftree-vrp -fwrapv' misscompiles stable gnupg-1.4.5.

--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-23 11:45 --- Testcase? ;) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC|

[Bug target/29560] New: Poor optimization for character shifts on Atmel AVR

For setting individual bits of a register, the construct unsigned char BitLocation = Whatever; REG |= (1< void setpin(unsigned char pin, unsigned char val) { if (val == 1) PORTC |= (1

[Bug target/29558] ICE in set_variable_part, at var-tracking.c:2140

--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-23 11:29 --- Fails on the 4.2.0 branch. On the 4.1 branch it might be due to packports of 2006-05-23 Alexandre Oliva <[EMAIL PROTECTED]> * simplify-rtx.c (simplify_subreg): Adjust REG_OFFSET for big-endian pa

  1   2   >