[Bug debug/23551] dwarf records for inlines appear incomplete

--- Comment #11 from aoliva at gcc dot gnu dot org 2006-11-01 06:37 --- Every inlined function starts with copying of argument initializers into the formal arguments. This makes such copies too suitable for SSA coalescing. It appears to me that it would be desirable to arrange for coal

[Bug libfortran/29302] nan_inf_fmt.f90 segfaults on Darwin PPC starting with Xcode 2.4

--- Comment #20 from howarth at nitro dot med dot uc dot edu 2006-11-01 06:06 --- Created an attachment (id=12525) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12525&action=view) assembly file from libgfortran/io/write.c on Darwin PPC -- http://gcc.gnu.org/bugzilla/show_bug.

[Bug c/11377] fault or warn modifiable static in extern inline definition

--- Comment #7 from geoffk at gcc dot gnu dot org 2006-11-01 05:40 --- This should now be fixed. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added

[Bug target/23067] Incorrect struct layout on darwin

--- Comment #28 from geoffk at gcc dot gnu dot org 2006-11-01 05:39 --- All these testcases are now fixed. I don't promise that the two compilers have exactly the same ABI, especially for C++, but the testcases pass. -- geoffk at gcc dot gnu dot org changed: What|Rem

[Bug c/16622] [C99] extern inline is handled wrong in C99 mode

--- Comment #17 from geoffk at gcc dot gnu dot org 2006-11-01 05:38 --- This should now be behaving correctly. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug target/15834] NO_IMPLICIT_EXTERN_C should be gotten rid of

--- Comment #10 from geoffk at gcc dot gnu dot org 2006-11-01 05:37 --- I can't tell if this bug is fixed. However, Darwin now has NO_IMPLICIT_EXTERN_C set. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added

[Bug target/23067] Incorrect struct layout on darwin

--- Comment #27 from pinskia at gcc dot gnu dot org 2006-11-01 05:33 --- I think this patch just broke structs with vectors in them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23067

[Bug target/23067] Incorrect struct layout on darwin

--- Comment #26 from geoffk at gcc dot gnu dot org 2006-11-01 05:28 --- Subject: Bug 23067 Author: geoffk Date: Wed Nov 1 05:28:41 2006 New Revision: 118365 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118365 Log: In gcc/: PR 23067 * c-decl.c (start_struct): D

[Bug libfortran/29302] nan_inf_fmt.f90 segfaults on Darwin PPC starting with Xcode 2.4

--- Comment #19 from howarth at nitro dot med dot uc dot edu 2006-11-01 05:10 --- Created an attachment (id=12524) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12524&action=view) preprocessed file for libgfortran/io/write.c on Darwin PPC -- http://gcc.gnu.org/bugzilla/show_b

[Bug middle-end/23470] a*a (for floats) is not considered always postive (-ffast-math only)

--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-01 05:10 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW

[Bug c/16622] [C99] extern inline is handled wrong in C99 mode

--- Comment #16 from pinskia at gcc dot gnu dot org 2006-11-01 05:07 --- http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00331.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622

[Bug c/16622] [C99] extern inline is handled wrong in C99 mode

--- Comment #15 from pinskia at gcc dot gnu dot org 2006-11-01 05:07 --- Why was this applied without a fixincludes for glibc? and a patch to glibc? Since GCC is the GNU Compiler Collection and glibc is the GNU libc so you need to also fix glibc at the same time and now you just broke

[Bug libfortran/29302] nan_inf_fmt.f90 segfaults on Darwin PPC starting with Xcode 2.4

--- Comment #18 from howarth at nitro dot med dot uc dot edu 2006-11-01 05:05 --- Andrew, I'll post the preprocessed source for write.c shortly. I did a quick test though moving... #define isfinite(x) (fpclassify(x) != FP_NAN && fpclassify(x) != FP_INFINITE) outside of the prepro

[Bug libfortran/29302] nan_inf_fmt.f90 segfaults on Darwin PPC starting with Xcode 2.4

--- Comment #17 from jvdelisle at gcc dot gnu dot org 2006-11-01 04:56 --- Jack is right about one thing and I should have noticed this. For that test case we should never get into output_float where we are segfaulting. The handling of nan and inf are handled in the calling function w

[Bug target/15834] NO_IMPLICIT_EXTERN_C should be gotten rid of

--- Comment #9 from geoffk at gcc dot gnu dot org 2006-11-01 04:53 --- Subject: Bug 15834 Author: geoffk Date: Wed Nov 1 04:53:33 2006 New Revision: 118358 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118358 Log: PR 15834 * config/darwin.h (NO_IMPLICIT_EXTERN_

[Bug c/11377] fault or warn modifiable static in extern inline definition

--- Comment #6 from geoffk at gcc dot gnu dot org 2006-11-01 04:48 --- Subject: Bug 11377 Author: geoffk Date: Wed Nov 1 04:48:15 2006 New Revision: 118357 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118357 Log: * c-decl.c (grokdeclarator): Don't set DECL_EXTERNAL on

[Bug c/16622] [C99] extern inline is handled wrong in C99 mode

--- Comment #14 from geoffk at gcc dot gnu dot org 2006-11-01 04:48 --- Subject: Bug 16622 Author: geoffk Date: Wed Nov 1 04:48:15 2006 New Revision: 118357 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118357 Log: * c-decl.c (grokdeclarator): Don't set DECL_EXTERNAL o

[Bug libfortran/29302] nan_inf_fmt.f90 segfaults on Darwin PPC starting with Xcode 2.4

--- Comment #16 from pinskia at gcc dot gnu dot org 2006-11-01 04:48 --- (In reply to comment #15) > I think it we need to cast both x variables in the macro to unsigned long. No, that would be incorrect. Jack, can you attach the preprocessed source for write.c? -- pinskia at gcc d

[Bug c/16622] [C99] extern inline is handled wrong in C99 mode

--- Comment #13 from geoffk at gcc dot gnu dot org 2006-11-01 04:47 --- Subject: Bug 16622 Author: geoffk Date: Wed Nov 1 04:47:30 2006 New Revision: 118356 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118356 Log: * c-decl.c (grokdeclarator): Don't set DECL_EXTERNAL o

[Bug c/11377] fault or warn modifiable static in extern inline definition

--- Comment #5 from geoffk at gcc dot gnu dot org 2006-11-01 04:47 --- Subject: Bug 11377 Author: geoffk Date: Wed Nov 1 04:47:30 2006 New Revision: 118356 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118356 Log: * c-decl.c (grokdeclarator): Don't set DECL_EXTERNAL on

[Bug libfortran/29302] nan_inf_fmt.f90 segfaults on Darwin PPC starting with Xcode 2.4

--- Comment #15 from howarth at nitro dot med dot uc dot edu 2006-11-01 04:33 --- I have pinned down the problem. On Darwin PPC with Xcode 2.4, at -O1 or higher we have problems with the isfinite() macro from libgfortran.h. For the nan_inf_fmt testcase it should always return 0, but

[Bug tree-optimization/23452] Optimizing CONJG_EXPR (a) * a

--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-01 04:30 --- (In reply to comment #3) > This is now fixed on mainline provided the user specifies -ffast-math. > There are some complications where imagpart(z*~z) can be non-zero, if > imagpart(z) is non-finite, such as an Inf or

[Bug middle-end/23470] a*a (for floats) is not considered always postive (-ffast-math only)

--- Comment #3 from sayle at gcc dot gnu dot org 2006-11-01 02:56 --- Subject: Bug 23470 Author: sayle Date: Wed Nov 1 02:56:45 2006 New Revision: 118355 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118355 Log: PR middle-end/23470 * tree.h (tree_expr_nonnegat

[Bug tree-optimization/29680] Misscompilation of spec2006 gcc

--- Comment #4 from dberlin at gcc dot gnu dot org 2006-11-01 01:29 --- Subject: Re: Misscompilation of spec2006 gcc > > --- Comment #3 from rakdver at gcc dot gnu dot org 2006-11-01 00:49 > --- > access_can_touch_variable determines that fde_13->dw_fde_cfi cannot touch > cie

[Bug tree-optimization/29680] Misscompilation of spec2006 gcc

--- Comment #3 from rakdver at gcc dot gnu dot org 2006-11-01 00:49 --- access_can_touch_variable determines that fde_13->dw_fde_cfi cannot touch cie_cfi_head; the list of virtual operands of the load thus becomes empty, and we insert SMT.48 for it. On *p, we cannot eliminate cie_cfi_he

[Bug tree-optimization/29680] Misscompilation of spec2006 gcc

--- Comment #2 from rakdver at gcc dot gnu dot org 2006-11-01 00:12 --- The problematic piece of .alias5 dump: p_27 = &fde_13->dw_fde_cfi; # VUSE ; D.1763_23 = fde_13->dw_fde_cfi; if (D.1763_23 != 0B) goto ; else goto ; # p_18 = PHI ; :; # cie_cfi_head_82 = V_MAY_DEF ;

[Bug tree-optimization/29680] Misscompilation of spec2006 gcc

--- Comment #1 from rakdver at gcc dot gnu dot org 2006-11-01 00:07 --- Created an attachment (id=12523) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12523&action=view) The testcase. -- rakdver at gcc dot gnu dot org changed: What|Removed |A

[Bug tree-optimization/29680] New: Misscompilation of spec2006 gcc

The fix for PR14784 causes misscompilation of gcc in spec2006, at -O2. Some discussion of the problem is in PR14784, I am moving it to a separate bug report. -- Summary: Misscompilation of spec2006 gcc Product: gcc Version: 4.3.0 Status: UNCONFIRMED

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

--- Comment #21 from pcarlini at suse dot de 2006-10-31 23:53 --- (In reply to comment #20) > I think we are totally misunderstood here. No, no, there is something *completely* different to it. Sorry, but I'm now convinced that you are here with the *wrong* spirit, aren't technical matt

[Bug fortran/29679] New: Inability to get shapes correct in initializations

In this code, the shape of 'a1(1,1:3)' in the initialization of b1 should be 3, but it is appearantly '1 3', i.e. we fail to remove the '1' from the shape-list. erik:~/gcc$ cat bug.f90 program init implicit none integer, parameter :: a1(2,6) = reshape([1, 2, 3, 4, 5, 6, 7, 8, 9, 10, &

[Bug fortran/29537] ICE in gfc_match_common for blank common in BLOCK DATA unit

--- Comment #13 from sgk at troutmask dot apl dot washington dot edu 2006-10-31 23:47 --- Subject: Re: ICE in gfc_match_common for blank common in BLOCK DATA unit On Tue, Oct 31, 2006 at 11:42:42PM -, aldot at gcc dot gnu dot org wrote: > > > Bernhard, > > > > This is ok for tr

[Bug fortran/29537] ICE in gfc_match_common for blank common in BLOCK DATA unit

--- Comment #12 from aldot at gcc dot gnu dot org 2006-10-31 23:42 --- (In reply to comment #10) > Bernhard, > > This is ok for trunk. Thanks. Worth backporting this to 4.2 (and 4.1) in a week or two? -- aldot at gcc dot gnu dot org changed: What|Removed

[Bug fortran/29537] ICE in gfc_match_common for blank common in BLOCK DATA unit

--- Comment #11 from aldot at gcc dot gnu dot org 2006-10-31 23:39 --- Subject: Bug 29537 Author: aldot Date: Tue Oct 31 23:38:58 2006 New Revision: 118347 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118347 Log: fortran/ChangeLog: 2006-11-01 Bernhard Fischer <[EMAIL PROTECT

[Bug rtl-optimization/29631] [4.1 regression] bug with promoted induction variable

--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-10-31 23:38 --- Should be fixed now. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added

[Bug rtl-optimization/29631] [4.1 regression] bug with promoted induction variable

* loop.c (basic_induction_var): Add new parameter inner_mode. : If set, convert the increment to it before sign-extending. : Likewise. : Set it. : Likewise. Return 0 if flag_wrapv. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/20061031-1.c

[Bug libfortran/29302] nan_inf_fmt.f90 segfaults on Darwin PPC starting with Xcode 2.4

--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-10-31 23:24 --- Jack, I don't think this is the final fix. However, after you test that other possibility I sent you I think I can finalize a patch. If zero terminating buffer does not solve the problem, then I think it confi

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

--- Comment #13 from hjl at lucon dot org 2006-10-31 22:22 --- Created an attachment (id=12522) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12522&action=view) A smaller testcase Here is a smaller testcase. -- hjl at lucon dot org changed: What|Removed

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

--- Comment #28 from vincent at vinc17 dot org 2006-10-31 22:15 --- (In reply to comment #27) > It's likely that I'll end up doing it, so would you please tell me how? According to the C rationale (I haven't checked), the sign of gamma(x) is -1 if [iff] x < 0 && remainder(floor(x), 2) !

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

--- Comment #12 from hjl at lucon dot org 2006-10-31 21:48 --- Created an attachment (id=12521) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12521&action=view) A testcase Here is a testcase. Both bad.s and good.s are compiled with -O2. The difference in assembly output is [EMAIL

[Bug fortran/29677] minimally informative gfortran -fbounds-check

--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-31 21:48 --- *** Bug 29678 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29677

[Bug fortran/29678] minimally informative gfortran -fbounds-check

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-31 21:48 --- *** This bug has been marked as a duplicate of 29677 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

[Bug fortran/29678] New: minimally informative gfortran -fbounds-check

My boss teared my hair off with heavy sarcasm when we turned on -fbound-check. The runtime executable proudly reported an array reference out of bounds. My boss screamed "Which bloody one?!" While I am very happy to know we have an array reference out of bounds I can see his point. Could the err

[Bug fortran/29677] minimally informative gfortran -fbounds-check

--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-31 21:41 --- The other thing is with debugging option such as -fbounds-check, you can also use gdb to figure out which one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29677

[Bug fortran/29677] minimally informative gfortran -fbounds-check

--- Comment #1 from kargl at gcc dot gnu dot org 2006-10-31 21:38 --- Upgrade to the a 4.2 pre-release version of gfortran or the mainline version. Please report back if you find a problem. -- kargl at gcc dot gnu dot org changed: What|Removed |Ad

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

--- Comment #3 from tobias dot burnus at physik dot fu-berlin dot de 2006-10-31 21:37 --- Steve Lionel from Intel wrote http://groups.google.com/group/comp.lang.fortran/tree/browse_frm/thread/062ce3447e5ef570/7e2c6b5723c3b228#doc_a7f0b804f755e27b "For a record length greater than 2,147

[Bug fortran/29677] New: minimally informative gfortran -fbounds-check

My boss teared my hair off with heavy sarcasm when we turned on -fbound-check. The runtime executable proudly reported an array reference out of bounds. My boss screamed "Which bloody one?!" While I am very happy to know we have an array reference out of bounds I can see his point. Could the err

[Bug libfortran/29627] partial unformatted reads shouldn't succeed

--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-10-31 20:58 --- Subject: Bug 29627 Author: tkoenig Date: Tue Oct 31 20:58:26 2006 New Revision: 118341 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118341 Log: 2006-10-31 Thomas Koenig <[EMAIL PROTECTED]> PR li

[Bug fortran/29067] Internal Error: gfc_resolve_expr(): Bad expression type

--- Comment #18 from fxcoudert at gcc dot gnu dot org 2006-10-31 20:15 --- Subject: Bug 29067 Author: fxcoudert Date: Tue Oct 31 20:15:22 2006 New Revision: 118338 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118338 Log: PR fortran/29067 * decl.c (gfc_set_con

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

--- Comment #27 from ghazi at gcc dot gnu dot org 2006-10-31 20:08 --- (In reply to comment #26) > Yes, it's true that it is useful to have this value. But determining it > separately is quite easy, without taking a noticeable additional time in > average. It's likely that I'll end up d

[Bug ada/27776] ICE on limited with and instantiation

--- Comment #3 from charlet at gcc dot gnu dot org 2006-10-31 19:41 --- Fixed on mainline. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added

[Bug bootstrap/29620] can not build libgcc.a on stage 1

--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-10-31 19:36 --- > Obsoleting sparc-sun-solaris2.5, if ever occurred for 4.1 branch, is > certainly not noted in neither `NEWS' nor `INSTALL/specific.html' of > 4.1.1 release. It is not obsolete, it is not supported. Sun did the

[Bug bootstrap/29620] can not build libgcc.a on stage 1

--- Comment #3 from gin at mo dot msk dot ru 2006-10-31 19:17 --- Subject: Re: can not build libgcc.a on stage 1 Obsoleting sparc-sun-solaris2.5, if ever occurred for 4.1 branch, is certainly not noted in neither `NEWS' nor `INSTALL/specific.html' of 4.1.1 release. -- http://gcc.g

[Bug c/29674] strtok_r function prototype does not match function definition

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-31 19:12 --- __strtok_r_1c is due to glibc having a define for strtok_r so this is not a bug -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug libfortran/29649] Force core dump on runtime library errors

--- Comment #7 from pinskia at physics dot uc dot edu 2006-10-31 19:10 --- Subject: Re: Force core dump on runtime library errors > - Support for coredumps (compile time? Environment variable? The latter > overwriting the former?) > [Advantage compile-time option: The core is there, i

Re: [Bug libfortran/29649] Force core dump on runtime library errors

> - Support for coredumps (compile time? Environment variable? The latter > overwriting the former?) > [Advantage compile-time option: The core is there, if one needs it. Advantage > run-time option: One can quickly turn it on, if needed.] > > - Traceback support more or less as outlined above (co

[Bug c/29674] New: strtok_r function prototype does not match function definition

Sees: When compiling using the -Wconversion flag the strtok_r the comppiler complains with a """ warning: passing argument 2 of ‘__strtok_r_1c’ with different width due to prototype """ Expects: No warning when the -Wconversion option is specified System Info: gcc (GCC) 4.1.1 20061011 (Red Hat

[Bug libfortran/29649] Force core dump on runtime library errors

--- Comment #6 from burnus at gcc dot gnu dot org 2006-10-31 18:37 --- > Using unwind is the way to go for a more serious solution. Looks nice as a starting point. (My biggest problem with developing this would be to find out whether it works on strange machines like Sparc, Windows etc.)

[Bug debug/29673] New: no -fdump-tree-inlined output

`-fdump-tree-inlined' creates no files. Environment: System: Linux 2.2.19-7.1.asp.2.gin #1 Tue Jun 15 16:42:13 MSD 2004 i686 unknown Architecture: i686 host: i686-pc-linux-gnu build: i686-pc-linux-gnu target: i686-pc-linux-gnu configured with: ../share/src/gcc-4.0.3/configure How-To-Repeat:

[Bug target/28975] conflicting declaration 'typedef struct mbstate_t mbstate_t'

--- Comment #5 from sje at cup dot hp dot com 2006-10-31 18:15 --- I forgot to include the PR number in my ChangeLog entry but this defect is fixed with the patch in comment #4. It has been backported to the 4.0, 4.1, and 4.2 branches as well as being checked in on the ToT. -- sje a

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

--- Comment #20 from l_heldt at poczta dot onet dot pl 2006-10-31 17:23 --- (In reply to comment #16) > (In reply to comment #15) > > I tried to prepare a simple testcase but without any success. It seems to be > > extremely hard to hit the moment when pointers are actually changed. Tri

[Bug target/24071] __gthread_active_p vs __gthread_once

--- Comment #14 from ebotcazou at gcc dot gnu dot org 2006-10-31 17:56 --- Subject: Bug 24071 Author: ebotcazou Date: Tue Oct 31 17:55:32 2006 New Revision: 118262 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118262 Log: PR target/24071 * gthr-posix.h (__gthre

[Bug target/24071] __gthread_active_p vs __gthread_once

--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-10-31 17:55 --- Subject: Bug 24071 Author: ebotcazou Date: Tue Oct 31 17:54:58 2006 New Revision: 118259 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118259 Log: PR target/24071 * gthr-posix.h (__gthre

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

--- Comment #19 from pcarlini at suse dot de 2006-10-31 17:01 --- Created an attachment (id=12520) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12520&action=view) Draft patch using the _M_get_mutex idiom for _M_invalidate This one, instead, using the _M_get_mutex idiom (similarly

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org |

[Bug fortran/24518] Intrinsic MOD incorrect for large arg1/arg2 and slow.

--- Comment #16 from paul dot richard dot thomas at cea dot fr 2006-10-31 16:14 --- Subject: RE: Intrinsic MOD incorrect for large arg1/arg2 and slow. FX, > > --- Comment #15 from fxcoudert at gcc dot gnu dot org > 2006-10-31 16:05 --- > (In reply to comment #14) > > It al

[Bug fortran/24518] Intrinsic MOD incorrect for large arg1/arg2 and slow.

--- Comment #17 from pault at gcc dot gnu dot org 2006-10-31 16:21 --- The fortran version of Uros' #13: real(8) :: x real(8) :: t = 0.0 x = 1000.0 do while (x > 0.0) t = t + mod (x, 1.7e-8) x = x - 1.0 end do print *, t end Yields: $ /irun/bin/gfortran -O2 -ma

[Bug fortran/24518] Intrinsic MOD incorrect for large arg1/arg2 and slow.

--- Comment #15 from fxcoudert at gcc dot gnu dot org 2006-10-31 16:05 --- (In reply to comment #14) > It also does MODULO correctly Why not use remainder{f,,l}? Is it incorrect? > although I am not sure that I understand why anybody > would use this intrinsic knowingly! Agreed :)

[Bug libfortran/29649] Force core dump on runtime library errors

--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-31 16:02 --- Created an attachment (id=12519) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12519&action=view) Example of how to use unwind for backtrace purposes The patch I was quoting in my previous comment; here, it

[Bug fortran/24518] Intrinsic MOD incorrect for large arg1/arg2 and slow.

--- Comment #14 from pault at gcc dot gnu dot org 2006-10-31 15:56 --- Created an attachment (id=12518) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12518&action=view) A fix for the PR: FX and Uros, I believe that this correctly detects the presence of the built_in. It also doe

[Bug libfortran/29649] Force core dump on runtime library errors

--- Comment #3 from burnus at gcc dot gnu dot org 2006-10-31 15:54 --- Nice idea. coredumping is easy, simply call "abort()" or kill(0,SIGSEGV)" and make sure that "ulimit -c" (csh: "limit core") shows a big enough number. This is actually what NAG f95 does and has the advantage that o

[Bug fortran/24518] Intrinsic MOD incorrect for large arg1/arg2 and slow.

--- Comment #18 from fxcoudert at gcc dot gnu dot org 2006-10-31 16:46 --- (In reply to comment #16) > I understood that remainder (a, b) = a - round (a/b) * b, whereas > mod (a, b) = a - int (a/b) * b > and modulo (a, b) = a - floor (a/b) * b Right you

[Bug java/29587] jc1: out of memory allocating 4072 bytes after a total of 708630224 bytes

--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-31 15:38 --- Subject: Re: jc1: out of memory allocating 4072 bytes after a total of 708630224 bytes > > jc1: out of memory allocating 4072 bytes after a total of 708630224 bytes > > > > similiar problem here. > > hp

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

--- Comment #17 from pcarlini at suse dot de 2006-10-31 14:30 --- Created an attachment (id=12517) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12517&action=view) Draft patch for the issue in Comment #8 only For the last issue, can you try this patch? If it works, then probably w

[Bug libfortran/29649] Force core dump on runtime library errors

--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-10-31 16:01 --- (In reply to comment #3) > coredumping is easy, simply call "abort()" or kill(0,SIGSEGV)" The usual signal to request a core dump is SIGQUIT. > However, I'm more a fan of either coredumping Same opinion here.

[Bug target/24071] __gthread_active_p vs __gthread_once

--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-10-31 18:02 --- Hopefully put to rest on mainline and 4.2 branch. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added -

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

--- Comment #14 from pcarlini at suse dot de 2006-10-31 13:23 --- (In reply to comment #13) > We actually encountered this problem - this is not taken from code review > only. Again, adding a mutex to that those *_base functions it's trivial. Now, please start preparing reduced testcas

[Bug libfortran/29302] nan_inf_fmt.f90 segfaults on Darwin PPC starting with Xcode 2.4

--- Comment #13 from howarth at nitro dot med dot uc dot edu 2006-10-31 14:14 --- As I mentioned to Jerry in a private email, his suggestion of... Index: io/write.c === --- io/write.c (revision 118229) +++ io/write.c (wo

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

--- Comment #9 from hjl at lucon dot org 2006-10-31 14:59 --- FYI, the fix for this bug miscompiles gcc in SPEC CPU 2006 on both x86 and x86-64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14784

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

--- Comment #11 from dberlin at gcc dot gnu dot org 2006-10-31 15:05 --- Subject: Re: [Tree-ssa] alias analysis deficiency Details, source, etc needed. On 31 Oct 2006 15:02:02 -, hjl at lucon dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #10 from hjl at lucon dot org

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

--- Comment #18 from bkoz at gcc dot gnu dot org 2006-10-31 14:37 --- > I tried to prepare a simple testcase but without any success. This is encouraging, that you attempted it. To be clear: we just need something that we can use to reproduce it. Please try for a complex or big testcase

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

Details, source, etc needed. On 31 Oct 2006 15:02:02 -, hjl at lucon dot org <[EMAIL PROTECTED]> wrote: --- Comment #10 from hjl at lucon dot org 2006-10-31 15:02 --- It miscompiles dwarf2out.c in gcc in SPEC CPU 2006.

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

--- Comment #10 from hjl at lucon dot org 2006-10-31 15:02 --- It miscompiles dwarf2out.c in gcc in SPEC CPU 2006. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14784

[Bug rtl-optimization/27883] [4.0/4.1 regression] in schedule_insns, at sched-rgn.c:3038 on mips

--- Comment #17 from amylaar at gcc dot gnu dot org 2006-10-31 14:34 --- (In reply to comment #4) > It is curious that life2 is running immediately before sched, instead of > immediately after combine. If we ran it immediately after combine, we could > get rid of the REG_DEAD/REG_UNUSE

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

--- Comment #16 from pcarlini at suse dot de 2006-10-31 13:45 --- (In reply to comment #15) > I tried to prepare a simple testcase but without any success. It seems to be > extremely hard to hit the moment when pointers are actually changed. Trivial > programs do not reveal the problem.

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

--- Comment #15 from l_heldt at poczta dot onet dot pl 2006-10-31 13:42 --- (In reply to comment #14) > (In reply to comment #13) > > We actually encountered this problem - this is not taken from code review > > only. > > Again, adding a mutex to that those *_base functions it's trivi

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

--- Comment #13 from l_heldt at poczta dot onet dot pl 2006-10-31 13:12 --- (In reply to comment #12) > About _M_detach_all specifically, it's called only by ~_Safe_sequence_base(), > thus only when the container itself is destructed. Therefore, I don't think it > may cause problems in

[Bug fortran/29671] preprocessor statements must start in column 1

--- Comment #2 from burnus at gcc dot gnu dot org 2006-10-31 13:02 --- Confirm and mark as enhancement. -- burnus at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/28662] fpp call of gfortran: -traditional-cpp versus newer macros like #x

--- Comment #3 from burnus at gcc dot gnu dot org 2006-10-31 13:03 --- Confirm my bug. See also 29671 ("#" must be in the first column). -- burnus at gcc dot gnu dot org changed: What|Removed |Added -

[Bug fortran/29651] Subroutine: Kind convertion of intent(out) value: signal

--- Comment #2 from burnus at gcc dot gnu dot org 2006-10-31 12:54 --- > This is a useful improvement to an enhancement, so I have marked it as > "enhancement". I'd call "improvement to an enhancement" an euphemism as it produces wrong code (uninitialized variables), albeit it is not ea

[Bug fortran/29671] preprocessor statements must start in column 1

--- Comment #1 from burnus at gcc dot gnu dot org 2006-10-31 12:48 --- The problem is that gfortran calls "cpp" with the -traditional-cpp option. This causes some more modern constructs not to work and it also is the reason behind your problem. (cf. PR 28662). We need to use -tradition

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

--- Comment #12 from pcarlini at suse dot de 2006-10-31 12:19 --- About _M_detach_all specifically, it's called only by ~_Safe_sequence_base(), thus only when the container itself is destructed. Therefore, I don't think it may cause problems in practice. -- http://gcc.gnu.org/bugzil

[Bug tree-optimization/29122] ICE with -ipa-cp and -m64 (tail calls)

--- Comment #6 from patchapp at dberlin dot org 2006-10-31 12:19 --- Subject: Bug number PR29122 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/msg01457.html -- http://gcc.gnu.org/bugzilla/sh

[Bug tree-optimization/29122] ICE with -ipa-cp and -m64 (tail calls)

--- Comment #5 from razya at il dot ibm dot com 2006-10-31 12:08 --- (In reply to comment #4) > Subject: Bug 29122 > Author: razya > Date: Tue Oct 31 11:36:28 2006 > New Revision: 118227 > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118227 > Log: > 2006-10-31 Razya Ladklesky

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

--- Comment #11 from pcarlini at suse dot de 2006-10-31 11:49 --- (In reply to comment #10) > ... that said, if we don't care *at all* about performance, fixing MT-safety > bugs in the _Safe_sequence or _Safe_iterator functions it's easy,... Of course I meant _Safe_sequence_base and _Sa

[Bug c/29186] optimzation breaks floating point exception flag reading

--- Comment #16 from kreckel at ginac dot de 2006-10-31 11:48 --- A quote from : "While on the subject of miscreant compilers, we should remark their increasingly common tendency to reorder operations that can be executed con

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

--- Comment #10 from pcarlini at suse dot de 2006-10-31 11:47 --- ... that said, if we don't care *at all* about performance, fixing MT-safety bugs in the _Safe_sequence or _Safe_iterator functions it's easy, just use everywhere the iterator_base_mutex. The nasty correctness problems are

[Bug fortran/29671] New: preprocessor statements must start in column 1

Preprocessor statements (as if|else|endif|error|warning) must start in colum 1, otherwise gfortran tries to handle them itself?! $> cat pp.F90 PROGRAM test_preprocessor #error "EEE" ! whitespace is significant END PROGRAM $> gfortran-4.3 -g -Wall pp.F90 In file pp.F90:3 #error "EEE" 1

[Bug libstdc++/29496] _M_invalidate function is not thread-safe in GLIBCXX_DEBUG mode

--- Comment #9 from pcarlini at suse dot de 2006-10-31 11:38 --- To be honest, I don't think this code has been designed with thread safety in mind. Fixing it completely after the fact is going to be very complex, I'm afraid. I'll try to spend some more time on those issues, but if Doug,

[Bug tree-optimization/29122] ICE with -ipa-cp and -m64 (tail calls)

--- Comment #4 from razya at gcc dot gnu dot org 2006-10-31 11:36 --- Subject: Bug 29122 Author: razya Date: Tue Oct 31 11:36:28 2006 New Revision: 118227 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118227 Log: 2006-10-31 Razya Ladklesky <[EMAIL PROTECTED]> * t

[Bug fortran/29670] [meta-bug] fortran interfaces

--- Comment #1 from pault at gcc dot gnu dot org 2006-10-31 11:26 --- (In reply to comment #0) > As suggested in PR29652, a meta-bug for interfaces in fortran. Oh thanks, Daniel - I was going to do it myself, so you have saved me a bit of hassle. We have a brief break from work (for Al

  1   2   >