[Bug debug/19523] [4.0/4.1/4.2/4.3 Regression] DBX_USE_BINCL support broken in the C++ compiler
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2008-01-06 08:07 --- > I don't like it much. I think it puts the work in the wrong place -- > libcpp and the lexer -- when, IMO, the problem should be addressed > by changing dbxout.c (and perhaps the debug API). I'm afraid that changing dbxout.c is out of the question at this point. Maybe we should simply concede defeat and close this as WONTFIX. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19523
[Bug fortran/34662] inout argument with parameter
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-06 09:08 --- Subject: Bug 34662 Author: burnus Date: Sun Jan 6 09:07:47 2008 New Revision: 131348 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131348 Log: 2008-01-06 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/34662 * interface.c (compare_actual_formal): Reject parameter actual to intent(out) dummy. 2008-01-06 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/34662 * gfortran.dg/intent_out_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/intent_out_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34662
[Bug fortran/34660] elemental and dummy procedure
--- Comment #4 from burnus at gcc dot gnu dot org 2008-01-06 09:19 --- Subject: Bug 34660 Author: burnus Date: Sun Jan 6 09:18:43 2008 New Revision: 131349 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131349 Log: 2008-01-06 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/34660 * resolve.c (resolve_formal_arglist): Reject dummy procedure in ELEMENTAL functions. 2008-01-06 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/34660 * gfortran.dg/elemental_args_check_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/elemental_args_check_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34660
[Bug fortran/34654] no unformatted on internal file
--- Comment #6 from burnus at gcc dot gnu dot org 2008-01-06 09:22 --- Subject: Bug 34654 Author: burnus Date: Sun Jan 6 09:21:27 2008 New Revision: 131350 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131350 Log: 2008-01-06 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/34654 * io.c (check_io_constraints): Disallow unformatted I/O for internal units. 2008-01-06 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/34654 * gfortran.dg/internal_io_unf.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/internal_io_unf.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34654
[Bug fortran/34387] FAIL: gfortran.dg/optional_dim_2.f90: FE vs library argument missmatch
--- Comment #14 from burnus at gcc dot gnu dot org 2008-01-06 09:39 --- Posted patch for this PR and PR 34540. http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00192.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34387
[Bug libfortran/34540] cshift, eoshift, kind=1 and kind=2 arguments...
--- Comment #18 from burnus at gcc dot gnu dot org 2008-01-06 09:40 --- Posted patch for this PR and PR 34387. http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00192.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34540
[Bug tree-optimization/34683] compile-time problem with -fstrict-aliasing
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-06 09:56 --- The problem is we have loads of unpartitionable SFTs. There are workarounds possible that only might affect performance of generated code, for example you can use --param salias-max-array-elements=0, which will reduce the number of unpartitionable SFTs somewhat. Or as a more big hammer, disable generating SFTs completely by --param max-fields-for-field-sensitive=0. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug fortran/34654] no unformatted on internal file
--- Comment #7 from burnus at gcc dot gnu dot org 2008-01-06 10:02 --- FIXED on the trunk (4.3.0). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34654
[Bug fortran/34660] elemental and dummy procedure
--- Comment #5 from burnus at gcc dot gnu dot org 2008-01-06 10:03 --- FIXED on the trunk (4.3.0). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34660
[Bug fortran/34662] inout argument with parameter
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-06 10:03 --- FIXED on the trunk (4.3.0). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34662
[Bug fortran/34683] Fortran FE generated IL pessimizes middle-end IL and analysis
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-06 10:07 --- Note that this shouldn't really be affected by strict aliasing or not. Note that the FE generated IL causes the first alias pass to emit too conservative alias info as well: # VUSE D.6049_4652 = atmp.1110.data; D.6050_4653 = (complex(kind=4)[0:] *) D.6049_4652; D.6051_4654 = S.1113_289 + D.3340_4634; # VUSE D.6052_4655 = (*D.6050_4653)[D.6051_4654]; I suppose the atmp.1110.data type is something like (void *), so the cast is required. But this really pessimizes the middle-end IL and it looks like the FE knows it will be complex(kind=4)[4] at the point of creation. Note fixing this will also improve optimization and thus runtime performance. I also see the FE creates lots of array temporaries: struct array2_complex(kind=4) atmp.1093; complex(kind=4) A.1094[4]; struct array2_complex(kind=4) atmp.1095; complex(kind=4) A.1096[4]; struct array2_complex(kind=4) atmp.1100; complex(kind=4) A.1101[4]; struct array2_complex(kind=4) atmp.1102; complex(kind=4) A.1103[4]; struct array2_complex(kind=4) atmp.1106; complex(kind=4) A.1107[4]; real(kind=4) D.3326; ... instead of re-using a single one. This also causes internal representation to blow up. So, to sum up, the situation could be significantly improved by improving the FE. (Like I noticed for I/O statements, where I provided a patch - that was not accepted - to share temporary variables created for the I/O context) As we already have bugs for the middle-end partitioning problems, I make this one a Fortran FE bug instead. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||33974 Component|tree-optimization |fortran Summary|compile-time problem with - |Fortran FE generated IL |fstrict-aliasing|pessimizes middle-end IL and ||analysis http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug fortran/34681] SAVEd derived type with allocatable components causes ICE
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-06 10:08 --- Patch posted by Paul: http://gcc.gnu.org/ml/fortran/2008-01/msg00048.html -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-06 10:08:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34681
[Bug fortran/34685] New: [patch] Honour parentheses in expressions
This is just a reminder to ensure that Richard's patch does not get forgotten: http://gcc.gnu.org/ml/fortran/2008-01/msg00019.html (especially since the patch tracker is currently down.) > > This adds a middle-end PAREN_EXPR tree code that acts as re-association > > barrier for floating point expressions. This allows to model the Fortran > > semantics that allow re-association for expressions that are not > > explicitly wrapped inside parentheses. -- Summary: [patch] Honour parentheses in expressions Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34685
[Bug fortran/34683] Fortran FE generated IL pessimizes middle-end IL and analysis
--- Comment #8 from burnus at gcc dot gnu dot org 2008-01-06 10:24 --- > So, to sum up, the situation could be significantly improved by improving > the FE. (Like I noticed for I/O statements, where I provided a patch - > that was not accepted - to share temporary variables created for the I/O > context) Could you add a link to that patch? I quickly searched my mail archive, but could not find it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug fortran/34683] Fortran FE generated IL pessimizes middle-end IL and analysis
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-01-06 10:34 ---
Basically, not re-using array descriptor variables is as bad as not re-using
I/O descriptor variables. I also wonder what this _gfortran_internal_{un,}pack
is about?
For
taux=gn(p2+p4)
gfortran generates
real(kind=4) A.1[4];
struct array1_real(kind=4) atmp.0;
atmp.0.dtype = 281;
atmp.0.dim[0].stride = 1;
atmp.0.dim[0].lbound = 0;
atmp.0.dim[0].ubound = 3;
atmp.0.data = (void *) &A.1;
atmp.0.offset = 0;
{
integer(kind=4) S.2;
S.2 = 0;
while (1)
{
if (S.2 > 3) goto L.1;
(*(real(kind=4)[0:] *) atmp.0.data)[S.2] = (*p2)[S.2] + (*p4)[S.2];
S.2 = S.2 + 1;
}
L.1:;
}
D.531 = _gfortran_internal_pack (&atmp.0);
D.533 = gn (D.531);
if ((real(kind=4)[0:] *) D.531 != (real(kind=4)[0:] *) atmp.0.data)
{
_gfortran_internal_unpack (&atmp.0, D.531);
{
void * D.532;
D.532 = D.531;
if (D.532 != 0B)
{
__builtin_free (D.532);
}
}
}
why does it not know the result of
if ((real(kind=4)[0:] *) D.531 != (real(kind=4)[0:] *) atmp.0.data)
at the point it creates the IL? I suppose this is about arrays with
stride != 1?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug fortran/34683] Fortran FE generated IL pessimizes middle-end IL and analysis
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-01-06 10:38 --- This one: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01762.html basically it mentiones async I/O as a reason to not do it, but instead the callee can copy the I/O structure in that case instead (it probably needs to anyway, as currently those structures live on the stack, so with async I/O you'd need otherwise to guarantee that the I/O finished before the current frame is left). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug fortran/34683] Fortran FE generated IL pessimizes middle-end IL and analysis
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-01-06 10:50 --- So, currently you can build up arbitrary large chains of virtual clobbers with write (*,*) 'hello' write (*,*) 'hello' ... as each of those writes create two un-partitionable SFTs. For arrays temporaries this is the same (no idea what is the most simple statement to create one). Without the fix for PR34093 this would even reliably ICE the compiler (and it of course creates compile-time and memory-usage problems, because the growth of the IL is non-linear). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug fortran/34683] Fortran FE generated IL pessimizes middle-end IL and analysis
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-01-06 11:09 --- Actually it isn't that bad for I/O as long as there are no pointers to the dt_parm structs in the IL (function arguments are ok). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug fortran/34683] Fortran FE generated IL pessimizes middle-end IL and analysis
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-01-06 11:13 --- For array temporaries the pinning of SFTs happens because we have the address of the actual array _data_ in the IL: # SFT.10_52 = VDEF atmp.0.data = &A.1; the array descriptor itself is not the problem (the redundant descriptors still consume memory, but should not cause compile-time problems where observed). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug fortran/34683] Fortran FE generated IL pessimizes middle-end IL and analysis
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-01-06 11:46 --- As of optimization, the conversion sequence atmp.0.data = &A.1; D.540_5 = atmp.0.data; D.541_6 = (real(kind=4)[0:] *) D.540_5; ... (*D.541_6)[S.5_1] = D.545_14; can be optimized to A.1[S.5_1] = D.545_14; with the following patch that makes sure we use (real(kind=4)[4] *) instead of the unknown size array type. Index: trans-types.c === --- trans-types.c (revision 131336) +++ trans-types.c (working copy) @@ -1511,10 +1511,12 @@ gfc_get_array_type_bounds (tree etype, i /* TODO: known offsets for descriptors. */ GFC_TYPE_ARRAY_OFFSET (fat_type) = NULL_TREE; - /* We define data as an unknown size array. Much better than doing + /* We define data as an array with the correct size. Much better than doing pointer arithmetic. */ arraytype = -build_array_type (etype, gfc_array_range_type); +build_array_type (etype, build_range_type (gfc_array_index_type, + gfc_index_zero_node, int_const_binop (MINUS_EXPR, stride, + integer_one_node, 0))); arraytype = build_pointer_type (arraytype); GFC_TYPE_ARRAY_DATAPTR_TYPE (fat_type) = arraytype; (the patch needs to be adjusted for the cases stride is not the actual array size, but you should get the idea) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug fortran/34685] [patch] Honour parentheses in expressions
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-06 12:01 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-06 12:01:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34685
[Bug fortran/34685] [patch] Honour parentheses in expressions
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-06 12:02 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-01-06 12:01:49 |2008-01-06 12:02:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34685
[Bug target/34682] 70% slowdown with SSE enabled
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-06 12:18 --- Please narrow down the particular loop in your testcase that gets slower. It looks like the testsuite measures several things. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34682
[Bug fortran/34686] New: Aliasing bug when returning character pointers
char_pointer_func.f90 is failing at -O3 on mips-linux-gnu because
of an aliasing bug. We have a function sfoo() that returns a pointer
to a string of length 4:
function sfoo () result (sc1)
character*4, pointer :: sc1
allocate (sc1)
sc1 = "abcd"
end function sfoo
It gets the C prototype:
static void sfoo (character(kind=1)[1:4] * &, integer(kind=4));
However, the first caller is:
c1 = sfoo ()
and it passes a 0-based array, pstr.3:
{
character(kind=1)[4] * pstr.3;
sfoo (&pstr.3, 4);
__builtin_memmove ((void *) c1, (void *) pstr.3, 4);
}
So after inlining sfoo(), we get the following code at final_cleanup:
D.617 = (character(kind=1)[1:4] *) D.616;
*(character(kind=1)[1:4] * &) &pstr.3 = D.617;
__builtin_memcpy (D.617, &"abcd"[1]{lb: 1 sz: 1}, 4);
__builtin_memmove (c1, pstr.3, 4);
where __builtin_memcpy is small enough to open-code; we do not use a call.
The two pointer types ([4]-based and [1:4]-based) have different alias sets,
so in the failing case, we then schedule the read of pstr.3 before the
store to *(character(kind=1)[1:4] * &) &pstr.3.
The problem appears to be in this part of gfc_conv_function_call.
which deliberately ignores the bounds on the return value:
/* Pass the string length. */
type = gfc_get_character_type (ts.kind, ts.cl);
type = build_pointer_type (type);
/* Return an address to a char[0:len-1]* temporary for
character pointers. */
if (sym->attr.pointer || sym->attr.allocatable)
{
/* Build char[0:len-1] * pstr. */
tmp = fold_build2 (MINUS_EXPR, gfc_charlen_type_node, len,
build_int_cst (gfc_charlen_type_node, 1));
tmp = build_range_type (gfc_array_index_type,
gfc_index_zero_node, tmp);
tmp = build_array_type (gfc_character1_type_node, tmp);
var = gfc_create_var (build_pointer_type (tmp), "pstr");
/* Provide an address expression for the function arguments. */
var = build_fold_addr_expr (var);
}
else
var = gfc_conv_string_tmp (se, type, len);
(I believe TYPE is unused in the sym->attr.pointer || sym->attr.allocatable
case).
--
Summary: Aliasing bug when returning character pointers
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rsandifo at gcc dot gnu dot org
GCC target triplet: mips-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34686
[Bug fortran/34686] Aliasing bug when returning character pointers
--- Comment #1 from rsandifo at gcc dot gnu dot org 2008-01-06 12:24 --- Testing a patch. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Known to fail||4.3.0 Last reconfirmed|-00-00 00:00:00 |2008-01-06 12:24:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34686
[Bug fortran/34683] Fortran FE generated IL pessimizes middle-end IL and analysis
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-01-06 12:07 --- Note that the large FRE compile-time is a dup of PR34450, try experimenting with --param sccvn-max-scc-size=N and find a N where the problem vanishes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug target/34684] Cross DLL Exceptions
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-06 12:29 --- This is a target specific issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34684
[Bug fortran/34685] [patch] Honour parentheses in expressions
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-06 12:52 --- I bet this also fixes PR 14741. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34685
[Bug ada/34674] Assert_Failure sinfo.adb:2141
--- Comment #3 from sam at gcc dot gnu dot org 2008-01-06 13:41 --- This is already fixed in the current SVN version. When you report bugs against an unreleased version, please make sure you use a recent one before reporting the bug. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34674
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
--- Comment #5 from joseph at codesourcery dot com 2008-01-06 15:12 --- Subject: Re: Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented) On Sat, 5 Jan 2008, rguenth at gcc dot gnu dot org wrote: > I wouldn't read the language this way. Because that will forcefully disable > all redundancy removing optimizations (which is what happens in this > testcase). > What it currently guards is expression rewriting that changes the outcome if > a rounding mode different than round-to-nearest is used. My understanding has always been that -frounding-math should be usable for the code that calls rounding-mode-changing functions, rather than having no way to compile that code safely with GCC, as well as the code that does not call those functions but may execute with non-default rounding modes. The FENV_ACCESS pragma does not distinguish between the two. > The finer-grained control the documentation mentions should not be globbed > to -frounding-math IMHO. The pragma would in effect set -frounding-math for particular regions of code; it isn't more fine-grained regarding whether the code sets the mode or merely runs under a different mode. It is of course possible that -frounding-math should be split into multiple options (more fine-grained than the pragma) as the other related flags have been split over time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
[Bug rtl-optimization/34263] missed optimization: cleanup loop latch (SMS)
--- Comment #1 from eres at il dot ibm dot com 2008-01-06 15:26 --- A patch was committed to trunk r131352. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34263
[Bug c++/31780] [4.2/4.3 regression] ICE with incompatible types for ?: with "complex type" conversion
--- Comment #23 from gdr at cs dot tamu dot edu 2008-01-06 15:28 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with
"complex type" conversion
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
| Subject: Re: [4.2/4.3 regression] ICE with incompatible types
| for ?: with "complex type" conversion
|
| gdr at cs dot tamu dot edu wrote:
|
| > | > I'd rather distinguish the constructor taking __complex__ by adding
| > | > a dummy parameter:
| > | >
| > | >enum _DummyArg { };
| > | >complex(__complex__ double __z, _DummyArg);
| > |
| > | That will, however, break backwards compatibility for user programs (if
| > | any) relying on the constructor.
| >
| > That isn't a concern because I never published that constructor as a
| > contract in the interface of std::complex.
|
| I'm not sure what you mean by that. It's a public constructor;
I mean that it is not a standard constructor, and it is not a
constructor I documented as a GNU extension. The fact that it is a
public constructor is not, by itself, a documentation that it is a
standard constructor or a constructor that users should use.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-06 15:57 --- I see. So basically we need to split all floating point operators into two variants, one specifying a default rounding mode is used and one specifying the rounding mode is unknown. I suppose the frontend parts would be actually quite simple then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
[Bug fortran/34658] save / common
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-06 16:20 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00200.html -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-01-04 07:26:43 |2008-01-06 16:20:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34658
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
--- Comment #7 from joseph at codesourcery dot com 2008-01-06 16:28 --- Subject: Re: Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented) On Sun, 6 Jan 2008, rguenth at gcc dot gnu dot org wrote: > I see. So basically we need to split all floating point operators into two > variants, one specifying a default rounding mode is used and one specifying > the > rounding mode is unknown. I suppose the frontend parts would be actually > quite > simple then? More than two variants, in the end, depending on how you handle all the other flags - but eventually, everything about GIMPLE semantics controlled by the global flags should be directly represented in the GIMPLE and the pragmas, together with the command-line options determining global defaults, would map to appropriate choices of operations / flags on those operations. This is desirable for LTO optimizing between objects compiled with different options as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
[Bug c++/34152] Erratic behaviour: Exception translation (throw from signal handlers)
--- Comment #7 from asteinarson at gmail dot com 2008-01-06 17:02 --- (In reply to comment #2) > Created an attachment (id=14728) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14728&action=view) [edit] > proposed fix > > I'm seeing similar behavior on x86-64 with both g++-4.1.3 (ubuntu-7.10 dist) > and g++-4.2.2 build from sources. I spent some time in the debugger and I've > identified the problem and a fix. > I've applied this path to GCC 4.3.0 (as of 2008-01-04). Unfortunately the problem is still there for me. Both in the original test case and in the non-call-except-cpp test case. Regards // ATS > > Thanks, > -Ted > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34152
[Bug target/34684] Cross DLL Exceptions
--- Comment #2 from XuHotdogs at gmail dot com 2008-01-06 17:18 --- (In reply to comment #1) > This is a target specific issue. > Yet in MinGW's release 3.4.5, the problem got solved. I don't know why this > happened again in GCC's official release 4.2.*. Are there anyone having the same problems? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34684
[Bug c++/34687] New: my gcc wont compile
I got a bug while I was trying to compile an emulator i got this error msg: gpp.exe internal error: (null) (program as) I use this line to compile: gpp -g GBA.gpp -o gba.exe -- Summary: my gcc wont compile Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jokehell2 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34687
[Bug c++/34687] my gcc wont compile
--- Comment #1 from jokehell2 at hotmail dot com 2008-01-06 18:02 --- Created an attachment (id=14886) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14886&action=view) one of the files got by the line suggested by bug reportin instructions -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34687
[Bug fortran/34655] 5.5.2.5
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-06 18:08 --- Subject: Bug 34655 Author: burnus Date: Sun Jan 6 18:07:52 2008 New Revision: 131353 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131353 Log: 2008-01-06 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/34655 * resolve.c (resolve_equivalence_derived): Reject derived types * with default initialization if equivalenced with COMMON variable. 2008-01-06 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/34655 * gfortran.dg/equiv_constraint_9.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/equiv_constraint_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34655
[Bug fortran/34655] 5.5.2.5
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-06 18:13 --- FIXED on the trunk (4.3.0). Patch: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00202.html -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34655
[Bug fortran/34658] save / common
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-06 18:17 --- FIXED on the trunk (4.3.0). Thanks for the bug report! -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34658
[Bug fortran/34658] save / common
--- Comment #4 from burnus at gcc dot gnu dot org 2008-01-06 18:17 --- Subject: Bug 34658 Author: burnus Date: Sun Jan 6 18:17:14 2008 New Revision: 131355 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131355 Log: 2007-01-06 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/34658 * match.c (gfc_match_common): Remove blank common in DATA BLOCK warning. * resolve.c (resolve_common_vars): New function. (resolve_common_blocks): Move checks to resolve_common_vars and invoke that function. (resolve_types): Call resolve_common_vars for blank commons. 2007-01-06 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/34658 * gfortran.dg/common_11.f90: New. * gfortran.dg/blockdata_1.f90: Update test case. * gfortran.dg/blockdata_2.f90: Update test case. Added: trunk/gcc/testsuite/gfortran.dg/common_11.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/blockdata_1.f90 trunk/gcc/testsuite/gfortran.dg/blockdata_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34658
[Bug fortran/34387] FAIL: gfortran.dg/optional_dim_2.f90: FE vs library argument missmatch
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2008-01-06 18:19 --- Subject: Bug 34387 Author: jvdelisle Date: Sun Jan 6 18:19:06 2008 New Revision: 131356 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131356 Log: 2008-01-06 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/34387 * trans-expr.c (gfc_conv_missing_dummy): Use a temporary to type convert the dummy variable expression, test for NULL, and pass the variable address to the called function. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34387
[Bug middle-end/34688] New: [4.1/4.2] ICE: output_operand: invalid expression as operand
[ Forwarded from http://bugs.debian.org/459429 ] With 4.1 and 4.2 we get the following ICE on m68k with -O2. This doesn't happen with 4.3. (etch)3889:[EMAIL PROTECTED]: ..-m68k-20080106-r131352/gcc] ./xgcc -B. -c -O2 ~/erlexec.preprocessed.4.2.c ./erlexec.c: In function âbuild_args_from_stringâ: ./erlexec.c:1364: internal compiler error: output_operand: invalid expression as operand Please submit a full bug report, -- Summary: [4.1/4.2] ICE: output_operand: invalid expression as operand Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com GCC target triplet: m68k-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34688
[Bug middle-end/34688] [4.1/4.2] ICE: output_operand: invalid expression as operand
--- Comment #1 from tbm at cyrius dot com 2008-01-06 18:23 --- Created an attachment (id=14887) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14887&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34688
[Bug fortran/34689] New: [4.3 Regression] libgomp.fortran/appendix-a/a.33.3.f90 -O (test for excess errors)
On Linux/Intel64, revision 131352 has FAIL: libgomp.fortran/appendix-a/a.33.3.f90 -O (test for excess errors) FAIL: libgomp.fortran/appendix-a/a.38.1.f90 -O (test for excess errors) FAIL: libgomp.fortran/appendix-a/a.33.3.f90 -O (test for excess errors) FAIL: libgomp.fortran/appendix-a/a.38.1.f90 -O (test for excess errors) Revision 131341 is OK. -- Summary: [4.3 Regression] libgomp.fortran/appendix-a/a.33.3.f90 -O (test for excess errors) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34689
[Bug fortran/34690] New: gfortran.dg/elemental_args_check_2.f90 doesn't work
On Linux/Intel64, I got FAIL: gfortran.dg/elemental_args_check_2.f90 -O (test for errors, line 14) FAIL: gfortran.dg/elemental_args_check_2.f90 -O (test for excess errors) with revision 131352. -- Summary: gfortran.dg/elemental_args_check_2.f90 doesn't work Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34690
[Bug libfortran/34540] cshift, eoshift, kind=1 and kind=2 arguments...
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2008-01-06 18:35 --- Subject: Bug 34540 Author: jvdelisle Date: Sun Jan 6 18:34:14 2008 New Revision: 131357 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131357 Log: 2008-01-06 Jerry DeLisle <[EMAIL PROTECTED]> PR libfortran/34540 * gfortran.dg/optional_dim_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/optional_dim_3.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34540
[Bug c++/34687] my gcc wont compile
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-06 18:37 --- > gpp.exe internal error: (null) (program as) as is crashing and as is part of the binutils project. Can you give the output of compiling and add -v ? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34687
[Bug fortran/34387] FAIL: gfortran.dg/optional_dim_2.f90: FE vs library argument missmatch
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2008-01-06 18:40 --- Fixed on trunk. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34387
[Bug libfortran/34540] cshift, eoshift, kind=1 and kind=2 arguments...
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2008-01-06 18:40 --- Fixed with patch to 34387. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34540
[Bug fortran/34545] ICE when compiling Fortran 95 code
--- Comment #15 from burnus at gcc dot gnu dot org 2008-01-06 18:48 --- Patch: http://gcc.gnu.org/ml/fortran/2008-01/msg00017.html Paul, what is with your patch (see above)? (I OKed it a few days ago.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
[Bug libgomp/34689] [4.3 Regression] libgomp.fortran/appendix-a/a.33.3.f90 -O (test for excess errors)
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-01-06 18:57 --- I can't remember any recent OMP-related changes in gfortran?! Moving to component libgomp, adding Jakub as CC. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org, jakub at gcc dot gnu ||dot org Component|fortran |libgomp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34689
[Bug fortran/34689] [4.3 Regression] libgomp.fortran/appendix-a/a.33.3.f90 -O (test for excess errors)
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-06 19:04 --- Mine. Try gfortran on the test case and you see why it is mine - it has nothing to do with OpenMP. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC|jakub at gcc dot gnu dot org| AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Component|libgomp |fortran Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-06 19:04:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34689
[Bug fortran/34659] [4.3 Regression] corner case continuation line
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-01-06 19:24 --- This is a regression. I thought in the back of my mind that I had this working right before. Sure enough, 4.2 gives a warning. gfc42 -static pr34659.f90 Warning: '&' not allowed by itself in line 1 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Summary|corner case continuation|[4.3 Regression] corner case |line|continuation line http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34659
[Bug libstdc++/34680] [4.3 Regression] Unconditional use of dynamic_cast in locale_facets.tcc breaks compilation with -fno-rtti
--- Comment #13 from mmitchel at gcc dot gnu dot org 2008-01-06 19:35 --- I'm not keen on silently changing dynamic_cast to static_cast. But, with -fno-rtti, making dynamic_cast and static casts work seems OK. Does that not work now? And, certainly, adding preprocessor macros (__GNU_CXX_EXCEPTIONS, __GNU_CXX_RTTI) to indicate whether or not exceptions and RTTI are turned on or not seems like a good idea. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34680
[Bug fortran/34689] [4.3 Regression] libgomp.fortran/appendix-a/a.33.3.f90 -O (test for excess errors)
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-06 19:37 --- Subject: Bug 34689 Author: burnus Date: Sun Jan 6 19:36:44 2008 New Revision: 131359 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131359 Log: 2008-01-06 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/34689 * interface.c (compare_actual_formal): Fix intent(out) check for function result variables. 2008-01-06 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/34689 * gfortran.dg/intent_out_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/intent_out_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34689
[Bug fortran/34689] [4.3 Regression] libgomp.fortran/appendix-a/a.33.3.f90 -O (test for excess errors)
--- Comment #4 from burnus at gcc dot gnu dot org 2008-01-06 19:47 --- FIXED on the trunk (4.3.0). Caused by the fix for PR34662. Thanks for the report. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34689
[Bug c++/34691] New: Default argument checking not performed after overload resolution.
The following code is ill-formed according to the standard, but accepted by
GCC:
namespace A {
extern "C" void f(int = 5);
}
namespace B {
extern "C" void f(int = 4);
}
using A::f;
using B::f;
int main() {
f(3);//OK
f(); //ERROR
}
When a default argument is used as in the second call, it needs to be looked up
to make sure it isn't declared twice. If it is, then it's an error. GCC will
also accept the code whether the default arguments to f() are given the same or
different values.
--
Summary: Default argument checking not performed after overload
resolution.
Product: gcc
Version: 4.1.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rideau3 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34691
[Bug libstdc++/34680] [4.3 Regression] Unconditional use of dynamic_cast in locale_facets.tcc breaks compilation with -fno-rtti
--- Comment #14 from pcarlini at suse dot de 2008-01-06 20:05 --- (In reply to comment #13) > I'm not keen on silently changing dynamic_cast to static_cast. But, with > -fno-rtti, making dynamic_cast and static casts work seems OK. Does > that not work now? Yes, I checked, and that works. > And, certainly, adding preprocessor macros (__GNU_CXX_EXCEPTIONS, > __GNU_CXX_RTTI) to indicate whether or not exceptions and RTTI are turned on > or > not seems like a good idea. Great. We can use that for a library-only solution. Today I posted a patch, we already have __EXCEPTIONS, and, for the new one, I choosen __GXX_RTTI consistently with other existing C++ only predefine macros, if you would rather prefer __GNU_CXX_RTTI, just let me know... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34680
[Bug fortran/34689] [4.3 Regression] libgomp.fortran/appendix-a/a.33.3.f90 -O (test for excess errors)
--- Comment #5 from burnus at gcc dot gnu dot org 2008-01-06 20:18 --- Subject: Bug 34689 Author: burnus Date: Sun Jan 6 20:18:01 2008 New Revision: 131360 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131360 Log: 2008-01-06 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/34689 * gfortran.dg/intent_out_4.f90: Fix test case. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/intent_out_4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34689
[Bug c++/34152] Erratic behaviour: Exception translation (throw from signal handlers)
--- Comment #8 from jakub at gcc dot gnu dot org 2008-01-06 20:26 --- Subject: Bug 34152 Author: jakub Date: Sun Jan 6 20:25:57 2008 New Revision: 131361 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131361 Log: PR c++/34152 * libsupc++/eh_personality.cc (PERSONALITY_FUNCTION): Check _GLIBCXX_HAVE_GETIPINFO instead of HAVE_GETIPINFO. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/libsupc++/eh_personality.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34152
[Bug fortran/34690] gfortran.dg/elemental_args_check_2.f90 doesn't work
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-06 20:30 --- Subject: Bug 34690 Author: burnus Date: Sun Jan 6 20:30:10 2008 New Revision: 131362 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131362 Log: 2008-01-06 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/34690 * gfortran.dg/elemental_args_check_2.f90: Fix test case. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/elemental_args_check_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34690
[Bug fortran/34690] gfortran.dg/elemental_args_check_2.f90 doesn't work
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-06 20:31 --- FIXED my stupid mistake on the trunk (4.3.0) by changing the test case. Introduced test case as fix for PR34660. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34690
[Bug fortran/34545] ICE when compiling Fortran 95 code
--- Comment #16 from paulthomas2 at wanadoo dot fr 2008-01-06 20:39 --- Subject: Re: ICE when compiling Fortran 95 code Tobias, Nothing - I have just updated to FC8 and blew all my nice set-up to pieces. This is the first time that Fedora has let me down. I will be operational first thing tomorrow morning - I just got back in action about 20 minutes ago but am too dog-tired to do anything right now. BTW The PR34431 etc. patch is coming along. I have cured all the regressions but have found other, very curious bugs. eg. integer (kind(1_8)) foo () fails with the patch. The bailing out to defer kind association until USE and IMPORT are over is too soon - the kind expression needs to be converted and, on the basis of the expression, the deferral mechanism triggered. I think that it is sufficient to do this if the expression contains a variable. I am pretty sure that I know what I have to do to complete this but it will take a couple of days yet. I'll tidy up the statement decoding, whilst I am about it. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
[Bug c++/34691] [4.1/4.2/4.3 Regression] Default argument checking not performed after overload resolution with C linkage
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-06 20:54 --- 2.95.4 says t.C:9: `B::f(int)' conflicts with used function t.C:2: `void A::f(int = 5)' previously declared here t.C:9: default argument given for parameter 1 of `void B::f(int = 4)' t.C:2: after previous specification in `void A::f(int = 5)' fails since at least 3.3.6. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Known to fail||3.3.6 Known to work||2.95.4 Last reconfirmed|-00-00 00:00:00 |2008-01-06 20:54:23 date|| Summary|Default argument checking |[4.1/4.2/4.3 Regression] |not performed after overload|Default argument checking |resolution with C linkage |not performed after overload ||resolution with C linkage Target Milestone|--- |4.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34691
[Bug c++/31780] [4.2/4.3 regression] ICE with incompatible types for ?: with "complex type" conversion
--- Comment #24 from mark at codesourcery dot com 2008-01-06 21:06 --- Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with "complex type" conversion gdr at cs dot tamu dot edu wrote: > | I'm not sure what you mean by that. It's a public constructor; > > I mean that it is not a standard constructor, and it is not a > constructor I documented as a GNU extension. The fact that it is a > public constructor is not, by itself, a documentation that it is a > standard constructor or a constructor that users should use. But, it's also not documentation that users should *not* use it. And, now it's been out there for a long time, so it's quite likely that some users somewhere *are* using it. The run-time library has various extensions to the standard, and the way people use a run-time library is partly to open its header files and use what they see. I think we have to accept that this is indeed an incompatible change and likely to affect users. That said, I do think it's reasonable to break backwards compatibility here if we have no other choice. Right now, we have this odd wart in the language with our handling of __complex__ (treating is as a non-artithmetic type) which causes other problems. So, it's possible that we have to choose between making an incompatible change to the library and leaving the language wart -- and I think we're all agreed that in that case we'd rather add the dummy parameter you suggest. But, you've not shown that my suggestion of adding additional constructors is detectable by users. If it's not, then that would be a better solution: it would allow us to avoid the incompatible change to the library. Of course, if adding constructors itself breaks compatibility, then that's a powerful argument against my suggestion. So far, all you've said is that it makes you nervous. Does it actually break something? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
[Bug target/34150] ICE: output_operand: invalid expression as operand on hppa
--- Comment #3 from danglin at gcc dot gnu dot org 2008-01-06 21:35 ---
This bug is present on 4.2 branch but head doesn't fail for me. The problem
is a deleted label.
Breakpoint 1, output_operand (x=0x4be5a208, code=0)
at ../../gcc/gcc/final.c:3171
3171 gcc_assert (!x || !REG_P (x) || REGNO (x) < FIRST_PSEUDO_REGISTER);
(gdb) p debug_rtx (x)
(note/s 1897 4221 1898 ("*.LJpc=819954") NOTE_INSN_DELETED_LABEL 13722)
$1 = void
(gdb) bt
#0 output_operand (x=0x4be5a208, code=0) at ../../gcc/gcc/final.c:3171
#1 0x0013dc10 in output_asm_insn (template=,
operands=0x460ba0) at ../../gcc/gcc/final.c:3102
#2 0x0013e914 in final_scan_insn (insn=0x4bd755a0,
file=, optimize=,
nopeepholes=, seen=0xfafc2d48)
at ../../gcc/gcc/final.c:2468
#3 0x0013eab4 in final_scan_insn (insn=0x4bf32cd0, file=0x48c670,
optimize=, nopeepholes=,
seen=0xfafc2d48) at ../../gcc/gcc/final.c:2143
#4 0x0013ed48 in final (first=, file=0x48c670,
optimize=2) at ../../gcc/gcc/final.c:1610
#5 0x0013ee48 in rest_of_handle_final () at ../../gcc/gcc/final.c:3916
#6 0x002404b0 in execute_one_pass (pass=0x43924c)
at ../../gcc/gcc/passes.c:881
#7 0x00240630 in execute_pass_list (pass=0x43924c)
at ../../gcc/gcc/passes.c:932
#8 0x00240644 in execute_pass_list (pass=0x439e58)
at ../../gcc/gcc/passes.c:933
#9 0x00240644 in execute_pass_list (pass=0x439e24)
at ../../gcc/gcc/passes.c:933
#10 0x00077834 in tree_rest_of_compilation (fndecl=0x49d9de00)
at ../../gcc/gcc/tree-optimize.c:462
---Type to continue, or q to quit---q
Quit
(gdb) frame 2
#2 0x0013e914 in final_scan_insn (insn=0x4bd755a0,
file=, optimize=,
nopeepholes=, seen=0xfafc2d48)
at ../../gcc/gcc/final.c:2468
2468output_asm_insn (template, recog_data.operand);
(gdb) p debug_rtx (insn)
(jump_insn:TI 1452 1450 1455 (set (pc)
(if_then_else (eq (reg:SI 28 %r28 [orig:1024+-3 ] [1024])
(const_int 0 [0x0]))
(label_ref [1897 deleted])
(pc))) 25 {*pa.md:1712} (nil)
(expr_list:REG_BR_PRED (const_int 50 [0x32])
(expr_list:REG_DEAD (reg:SI 28 %r28 [orig:1024+-3 ] [1024])
(expr_list:REG_BR_PROB (const_int 200 [0xc8])
(nil)
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-01-06 21:35:49
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34150
[Bug preprocessor/34692] New: [4.2/4.3 regression]
The following testcase triggers an internal error in the preprocessor
since GCC 4.2.0:
#define FOO(expr) (#expr)
FOO(
#pragma GCC diagnostic
)
bug.c:5:1: internal error: unspellable token PRAGMA
bug.c:5:1: internal error: unspellable token PRAGMA_EOL
bug.c:3: error: expected identifier or '(' before string constant
This is similar to PR34602, but not yet fixed on mainline.
--
Summary: [4.2/4.3 regression]
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34692
[Bug preprocessor/34692] [4.2/4.3 regression] Internal error with prgama in macro
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||34602 Keywords||ice-on-invalid-code Summary|[4.2/4.3 regression]|[4.2/4.3 regression] ||Internal error with prgama ||in macro Target Milestone|--- |4.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34692
[Bug libfortran/34670] bounds checking for array intrinsics
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-01-06 21:44 --- Created an attachment (id=14888) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14888&action=view) partial implementation This is an implementation for the array intrinsics, but I'm having trouble with writing test cases. See next attachment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34670
[Bug fortran/34693] New: [4.3 Regression] gfortran.dg/common_6.f90 -O
On Linux/Intel64, revision 131362 gives FAIL: gfortran.dg/common_6.f90 -O (internal compiler error) FAIL: gfortran.dg/common_6.f90 -O (test for excess errors) Revision 131352 is OK. -- Summary: [4.3 Regression] gfortran.dg/common_6.f90 -O Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34693
[Bug libfortran/34670] bounds checking for array intrinsics
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-01-06 21:46 --- Created an attachment (id=14889) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14889&action=view) Test case that doesn't work This test case fails with my patch, although the "dg-shouldfail" directive should take care of that. Does anybody have any idea what I could do here? If I can't get this to work, I'll submit the patch without test cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34670
[Bug fortran/34693] [4.3 Regression] gfortran.dg/common_6.f90 -O
--- Comment #1 from hjl at lucon dot org 2008-01-06 21:47 --- It may be introduced by the fix for bug 34658. -- hjl at lucon dot org changed: What|Removed |Added OtherBugsDependingO||34658 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34693
[Bug fortran/34693] [4.3 Regression] gfortran.dg/common_6.f90 -O
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-06 21:50 --- To my understanding the problem existed before though it did not crash as often as it does now. Before it failed here only with -m64 now also with -m32, but I believe it is the same problem and thus unrelated to the fix of PR34658. *** This bug has been marked as a duplicate of 33375 *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34693
[Bug fortran/33375] ICE (segfault) gfortran.dg/common_6.f90
--- Comment #5 from burnus at gcc dot gnu dot org 2008-01-06 21:50 --- *** Bug 34693 has been marked as a duplicate of this bug. *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33375
[Bug fortran/34693] [4.3 Regression] gfortran.dg/common_6.f90 -O
--- Comment #3 from hjl at lucon dot org 2008-01-06 21:54 --- Why didn't I see it with revision 131352? -- hjl at lucon dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34693
[Bug middle-end/34694] New: [4.3 regression] Wrong line number for uninitialized variable
The warning for the following testcase contains a wrong line number
on mainline (compile with "-fopenmp -O -Wall"):
int i;
void foo()
{
#pragma omp parallel
{
int j;
i = j;
}
}
bug.c: In function 'foo.omp_fn.0':
bug.c:8: warning: 'j' is used uninitialized in this function
bug.c:8: note: 'j' was declared here
The variable 'j' is in fact declared in line 7, and not 8.
The regression appeared between 2007-08-15 and 2007-09-14.
The bug is triggered with the C and C++ frontend.
--
Summary: [4.3 regression] Wrong line number for uninitialized
variable
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34694
[Bug middle-end/34694] [4.3 regression] Wrong line number for uninitialized variable
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34694
[Bug middle-end/34694] [4.3 regression] Wrong line number for uninitialized variable
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |minor Keywords||openmp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34694
[Bug target/34150] ICE: output_operand: invalid expression as operand on hppa
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-06 21:59 --- Subject: Re: ICE: output_operand: invalid expression as operand on hppa > This bug is present on 4.2 branch but head doesn't fail for me. The problem > is a deleted label. The label is deleted in the dbr pass. The uses count seems wrong, but still the in_struct flag is set and the label should not have been deleted. Dave --- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-06 21:59 --- Created an attachment (id=14890) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14890&action=view) --- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-06 21:59 --- Created an attachment (id=14891) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14891&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34150
[Bug fortran/34545] ICE when compiling Fortran 95 code
--- Comment #17 from pault at gcc dot gnu dot org 2008-01-06 22:00 --- Subject: Bug 34545 Author: pault Date: Sun Jan 6 22:00:00 2008 New Revision: 131364 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131364 Log: 2008-01-06 Paul Thomas <[EMAIL PROTECTED]> PR fortran/34545 * module.c (load_needed): If the namespace has no proc_name give it the module symbol. 2008-01-06 Paul Thomas <[EMAIL PROTECTED]> PR fortran/34545 * gfortran.dg/use_12.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/use_12.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
[Bug fortran/34683] Fortran FE generated IL pessimizes middle-end IL and analysis
--- Comment #16 from jaydub66 at gmail dot com 2008-01-06 22:08 --- I've done some experimenting with older GCC versions I have floating around on my machines: Compiling the test case with both 4.1.2 and 4.2.1 gives an ICE, so I guess we can't exactly call this a regression. But then compiling with older 4.3 trunk builds works much better: I have a version from August 24 of last year, which runs the test case at full -O3 in a perfect 8sec, with 32MB memory usage (that is with --enable-checking=release). And I have two other builds from October 8 and November 9, which both run the test case in about 38s with 85MB mem-usage (they are built with --enable-checking=debug, so this is probably just debugging overhead). At least none of them takes the crazy 800MB of recent builds. To sum up: It seems like trunk versions up to at least November 9 seem to work fine on this test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug fortran/34683] Fortran FE generated IL pessimizes middle-end IL and analysis
--- Comment #17 from rguenther at suse dot de 2008-01-06 22:12 --- Subject: Re: Fortran FE generated IL pessimizes middle-end IL and analysis On Sun, 6 Jan 2008, jaydub66 at gmail dot com wrote: > --- Comment #16 from jaydub66 at gmail dot com 2008-01-06 22:08 --- > I've done some experimenting with older GCC versions I have floating around on > my machines: > > Compiling the test case with both 4.1.2 and 4.2.1 gives an ICE, so I guess we > can't exactly call this a regression. > > But then compiling with older 4.3 trunk builds works much better: > I have a version from August 24 of last year, which runs the test case at full > -O3 in a perfect 8sec, with 32MB memory usage (that is with > --enable-checking=release). And I have two other builds from October 8 and > November 9, which both run the test case in about 38s with 85MB mem-usage > (they > are built with --enable-checking=debug, so this is probably just debugging > overhead). At least none of them takes the crazy 800MB of recent builds. > > To sum up: It seems like trunk versions up to at least November 9 seem to work > fine on this test case. Well, we know what introduced this regression on the trunk. It was the fix for PR33870. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug middle-end/34683] [4.3 Regression] Fortran FE generated IL pessimizes middle-end IL and analysis
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||33870 Component|fortran |middle-end Summary|Fortran FE generated IL |[4.3 Regression] Fortran FE |pessimizes middle-end IL and|generated IL pessimizes |analysis|middle-end IL and analysis Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug preprocessor/34692] [4.2/4.3 regression] Internal error with pragma in macro
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-06 22:14 --- I think this was introduced with the pragma changes from the openmp branch. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34692
[Bug preprocessor/34695] New: Preprocessor warning->error conversion from -Werror is silent
When -Werror is passed in, libcpp silently converts warnings to errors: $ gcc foo.c -Wall -Werror foo.c:3:1: error: "FOO" redefined foo.c:2:1: error: this is the location of the previous definition This is potentially confusing, and inconsistent with cc, which displays: $ gcc foo.c -Wall -Werror cc1: warnings being treated as errors foo.c:1: warning: return type defaults to ‘int’ foo.c: In function ‘main’: foo.c:1: warning: control reaches end of non-void function -- Summary: Preprocessor warning->error conversion from -Werror is silent Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ed at catmur dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34695
[Bug fortran/34693] [4.3 Regression] gfortran.dg/common_6.f90 -O
--- Comment #4 from burnus at gcc dot gnu dot org 2008-01-06 22:23 --- I don't know. When I investigated PR 33375, I found that that the symbol existed but was uninitialized. I do not understand why it started to fail with x86-64 but valgrind showed it used also before uninitialized memory. I assume that now that one accesses the symbol much more often, the chance of crashes increases. At least it now also crashes here for -m32. But as the symptoms are the same (crash for invalid COMMON) and as valgrind shows the same error (invalid read), I still believe this is a duplicate of PR 33375. You can try valgrind with an older version. *** This bug has been marked as a duplicate of 33375 *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34693
[Bug fortran/33375] ICE (segfault) gfortran.dg/common_6.f90
--- Comment #6 from burnus at gcc dot gnu dot org 2008-01-06 22:23 --- *** Bug 34693 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33375
[Bug c++/33665] [4.1/4.2 regression] Bogus warning: `this.0' is used uninitialized in this function
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-01-06 22:30
---
Confirmed. Here's a further reduced testcase that triggers the warning
already with "-O -Wall":
struct A {};
struct B : A
{
double x, y;
B() : x(), y() {}
};
inline B getB()
{
return B();
}
struct C : B
{
C() : B(getB()) {}
};
C c;
bug.cc: In function 'void __static_initialization_and_destruction_0(int, int)':
bug.cc:7: warning: 'this.0' is used uninitialized in this function
bug.cc:7: note: 'this.0' was declared here
The bug appeared in GCC 4.1.2, but seems to be fixed on mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||diagnostic
Last reconfirmed|-00-00 00:00:00 |2008-01-06 22:30:19
date||
Summary|Warning: `this.11' is used |[4.1/4.2 regression] Bogus
|uninitialized in this |warning: `this.0' is used
|function|uninitialized in this
||function
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33665
[Bug libstdc++/34680] [4.3 Regression] Unconditional use of dynamic_cast in locale_facets.tcc breaks compilation with -fno-rtti
--- Comment #15 from paolo at gcc dot gnu dot org 2008-01-06 22:31 --- Subject: Bug 34680 Author: paolo Date: Sun Jan 6 22:30:32 2008 New Revision: 131366 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131366 Log: gcc/ 2008-01-06 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/34680 * c-cppbuiltin.c (c_cpp_builtins): Define __GXX_RTTI, if appropriate. * doc/cpp.texi ([Common Predefined Macros]): Document. gcc/testsuite/ 2008-01-06 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/34680 * g++.dg/rtti/predefined-rtti-macro-1.C: New. * g++.dg/rtti/predefined-rtti-macro-2.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/rtti/predefined-rtti-macro-1.C trunk/gcc/testsuite/g++.dg/rtti/predefined-rtti-macro-2.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-cppbuiltin.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34680
[Bug preprocessor/34695] Preprocessor warning->error conversion from -Werror is silent
--- Comment #1 from ed at catmur dot co dot uk 2008-01-06 22:35 --- Created an attachment (id=14892) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14892&action=view) gcc-cpp-Werror-message.patch Proposed patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34695
[Bug libfortran/34669] libgfortran doesn't build with -pipe
--- Comment #2 from steven at gcc dot gnu dot org 2008-01-06 22:40 --- See http://gcc.gnu.org/ml/fortran/2008-01/msg00067.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34669
[Bug c++/34696] New: Overloaded template losing type in invoking a superclass method?
Given the following test program:
#include
#include
class X : private std::ostringstream {
public:
template X &operator<<(a arg)
{
#if 0
std::ostringstream &o= *this;
o << arg;
#else
std::ostringstream::operator<<(arg);
#endif
return *this;
}
using std::ostringstream::str;
};
int main(int argc, char **argv)
{
X x;
x << "foo";
std::cerr << x.str() << std::endl;
}
The output that I get is:
$ ./t
0x4014f0
... or some other hexadecimal pointer value.
If I change the "#if 0" to "#if 1" and compile the alternate version, I get the
expected results:
$ ./t
foo
After staring at this for a while, I can't see what the difference is here. It
almost looks like "std::ostringstream::operator<<(arg)" ends up invoking
std::ostringstream::operator<<(void *) even though arg's type is char * (or a
const char *).
--
Summary: Overloaded template losing type in invoking a superclass
method?
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrsam at courier-mta dot com
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34696
[Bug fortran/34659] [4.3 Regression] corner case continuation line
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-01-06 23:11 --- This trivial patch fixes this: Index: scanner.c === --- scanner.c (revision 131355) +++ scanner.c (working copy) @@ -1176,7 +1176,7 @@ load_line (FILE *input, char **pbuf, int seen_ampersand = 1; } - if ((c != '&' && c != '!') || (c == '!' && !seen_ampersand)) + if ((c != '&' && c != '!' && c != ' ') || (c == '!' && !seen_ampersand)) seen_printable = 1; /* Is this a fixed-form comment? */ I will commit as such and add a test case. I may refine on this a bit. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34659
[Bug c++/34152] Erratic behaviour: Exception translation (throw from signal handlers)
--- Comment #9 from asteinarson at gmail dot com 2008-01-06 23:18 --- (In reply to comment #8) > Subject: Bug 34152 > > Author: jakub > Date: Sun Jan 6 20:25:57 2008 > New Revision: 131361 > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131361 > Log: > PR c++/34152 > * libsupc++/eh_personality.cc (PERSONALITY_FUNCTION): Check > _GLIBCXX_HAVE_GETIPINFO instead of HAVE_GETIPINFO. I've checked this. From line 446 of libsupc++/eh_personality.cc: // Parse the LSDA header. p = parse_lsda_header (context, language_specific_data, &info); info.ttype_base = base_of_encoded_value (info.ttype_encoding, context); #ifdef _GLIBCXX_HAVE_GETIPINFO ip = _Unwind_GetIPInfo (context, &ip_before_insn); #else ip = _Unwind_GetIP (context); #endif I've rebuild with the patch in a clean directory. g++ --version gives: $ g++43 --version g++43 (GCC) 4.3.0 20080104 (experimental) Regards // ATS > > Modified: > trunk/libstdc++-v3/ChangeLog > trunk/libstdc++-v3/libsupc++/eh_personality.cc > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34152
[Bug c/34697] New: gcc -std=gnu99 emits global symbol for extern inline function declarations
Here's the source code:
extern inline void f() {}
int main () {}
Compile with
gcc -c -std=gnu99 filename.c
Use nm filename.o to see that a global symbol f has been declared, but it
shouldn't be.
This prevents libgmp from being usable under Mac OS 10.5.
% uname -a
Darwin indigo.local 9.1.0 Darwin Kernel Version 9.1.0: Wed Oct 31 17:46:22 PDT
2007; root:xnu-1228.0.2~1/RELEASE_I386 i386
--
Summary: gcc -std=gnu99 emits global symbol for extern inline
function declarations
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dan at math dot uiuc dot edu
GCC build triplet: i686-apple-darwin9
GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34697
[Bug c/34697] gcc -std=gnu99 emits global symbol for extern inline function declarations
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-06 23:25 --- Well extern inline for 4.3.0 and before in C99 mode was the GNU 89 extern inline and not the C99 extern inline. This was fixed for 4.3.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34697
[Bug middle-end/34150] ICE: output_operand: invalid expression as operand on hppa
--- Comment #7 from danglin at gcc dot gnu dot org 2008-01-06 23:27 ---
Breakpoint 1, delete_insn (insn=0x4be5a208) at ../../gcc/gcc/cfgrtl.c:111
111 if (LABEL_P (insn))
(gdb) bt
#0 delete_insn (insn=0x4be5a208) at ../../gcc/gcc/cfgrtl.c:111
#1 0x001a8f30 in delete_related_insns (insn=0x4be5a208)
at ../../gcc/gcc/jump.c:1411
#2 0x001a9ed8 in redirect_jump_2 (jump=0x4bd7aae0, olabel=0x4be5a208,
nlabel=0x4bf325c8, delete_unused=1, invert=0) at ../../gcc/gcc/jump.c:1702
#3 0x001aa03c in redirect_jump (jump=0x4bd7aae0, nlabel=0x4bf325c8,
delete_unused=1) at ../../gcc/gcc/jump.c:1659
#4 0x0035b40c in fill_slots_from_thread (insn=0x4bd7aae0,
condition=0x4000d218, thread=0x4bef85f0,
opposite_thread=, likely=1, thread_if_true=1,
own_thread=0, slots_to_fill=1, pslots_filled=0xfb5e0e08,
delay_list=0x4bf33180) at ../../gcc/gcc/reorg.c:2900
#5 0x0035c8c0 in fill_simple_delay_slots (non_jumps_p=0)
at ../../gcc/gcc/reorg.c:2363
#6 0x0035d548 in dbr_schedule (first=0x4bd17840) at ../../gcc/gcc/reorg.c:3611
#7 0x0035e5a0 in rest_of_handle_delay_slots () at ../../gcc/gcc/reorg.c:3784
#8 0x002404b0 in execute_one_pass (pass=0x43b828)
at ../../gcc/gcc/passes.c:881
#9 0x00240630 in execute_pass_list (pass=0x43b828)
at ../../gcc/gcc/passes.c:932
#10 0x00240644 in execute_pass_list (pass=0x439e58)
at ../../gcc/gcc/passes.c:933
#11 0x00240644 in execute_pass_list (pass=0x439e24)
---Type to continue, or q to quit---
at ../../gcc/gcc/passes.c:933
#12 0x00077834 in tree_rest_of_compilation (fndecl=0x49d9de00)
at ../../gcc/gcc/tree-optimize.c:462
#13 0x0027abe8 in cgraph_expand_function (node=0x4bc944d0)
at ../../gcc/gcc/cgraphunit.c:1243
#14 0x0027c5c8 in cgraph_assemble_pending_functions ()
at ../../gcc/gcc/cgraphunit.c:373
#15 0x0027c0e8 in cgraph_finalize_function (decl=0x49d9de00, nested=0 '\0')
at ../../gcc/gcc/cgraphunit.c:502
#16 0x0004ad94 in end_java_method () at ../../gcc/gcc/java/decl.c:2002
#17 0x00063af8 in parse_class_file () at ../../gcc/gcc/java/jcf-parse.c:956
#18 0x000663ac in java_parse_file (set_yydebug=)
at ../../gcc/gcc/java/jcf-parse.c:1450
#19 0x0021cec8 in toplev_main (argc=,
argv=) at ../../gcc/gcc/toplev.c:1032
#20 0x403b6234 in __libc_start_main () from /lib/libc.so.6
#21 0x0001bfb0 in _start ()
(gdb) p debug_rtx (insn)
(code_label/s 1897 4221 1898 13722 ("*.LJpc=819954") [0 uses])
$4 = void
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34150
