[Bug other/31349] [4.3 Regression] gcc -v --help returns no options for C, C++
--- Comment #8 from manu at gcc dot gnu dot org 2008-01-22 07:51 --- Can't we get this fixed soon? It is marked as a P2 regression. (In reply to comment #7) > Subject: Re: [4.3 Regression] gcc -v --help returns no options > You can find out all the options supported by a given language, > including the ones that it shares with other languages and including > those that do not have a description by using the --help= > feature. For example: So, instead of the current: The following options are specific to the language C: No options with the desired characteristics were found can't be said better: No options are specific to the language C: Use --help=c to list options supported by the language C. >% gcc --help=java >The following options are supported by the language Java: I should note that % gcc -v --help=c returns the following for me The following options are language-independent: --help Display this information --help= Display descriptions of a specific class of options. is one or more of optimizers, target, warnings, undocumented, params I think it should say "The following options are supported by the language C". Yes, some of those options may work on other languages, but they also may not work in all of them. Language-independent is ambiguous. > So I think that the bone of contention here is what should be listed by > "--help -v". I think that leaving out options which have no description > is a good default. If for no other reason than to encourage people to > write descriptions for the options so that they are then listed in the > --help output. I don't think it works like this. Few GCC devs would bother to use --help to find options. On the other hand, users will likely report a bug whenever they find "This switch lacks documentation". > Do you still feel that "--help -v" should list undocumented options ? I understand Brooks was asking to list options supported by each language rather than options specific to each language. Either way seems correct as long as you can get the other. He also was asking to list supported options without its description (independently whether they are documented or not) at the top as in: The Fortran front end recognizes the following options: -I, -Wall, -Wconversion, -fopenmp, -fpreprocessed, -fshort-enums -J Put MODULE files in 'directory' -Waliasing Warn about possible aliasing of dummy arguments My proposal would be: 1) Change the current empty message to mention --help= as described above. 2) List all options with --help -v, even if they are undocumented (abusing of -Wextra for this seems unjustified to me). I would further propose that if checking is enabled, then show the message "This switch lacks documentation", otherwise (for releases) just show the empty string "". Can we agree on this? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Last reconfirmed|2007-03-25 22:48:12 |2008-01-22 07:51:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31349
[Bug fortran/34899] Continuation lines with not recognized
--- Comment #6 from burnus at gcc dot gnu dot org 2008-01-22 07:34 --- Subject: Bug 34899 Author: burnus Date: Tue Jan 22 07:33:46 2008 New Revision: 131713 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131713 Log: 2008-01-22 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/34899 * scanner.c (load_line): Support continuation * lines. * invoke.texi (-Wtabs): Document this. 2008-01-22 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/34899 * gfortran.dg/tab_continuation.f: New. Added: trunk/gcc/testsuite/gfortran.dg/tab_continuation.f Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/scanner.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34899
[Bug c++/33984] [4.2/4.3 Regression] bit-fields, references and overloads
--- Comment #7 from aoliva at gcc dot gnu dot org 2008-01-22 06:44 --- Responded on gcc-patches, with revised patch. http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00988.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33984
[Bug c/34921] Misalign stack variable referenced by nested function
--- Comment #1 from Joey dot ye at intel dot com 2008-01-22 06:38 --- This patch should fix it: Index: gcc/tree-nested.c === --- gcc/tree-nested.c (revision 131342) +++ gcc/tree-nested.c (working copy) @@ -183,6 +183,10 @@ TREE_CHAIN (field) = *p; *p = field; + + /* Set correct alignment for frame struct type */ + if (TYPE_ALIGN(type) < DECL_ALIGN (field)) +TYPE_ALIGN(type) = DECL_ALIGN (field); } /* Build or return the RECORD_TYPE that describes the frame state that is -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34921
[Bug c/34921] New: Misalign stack variable referenced by nested function
> cat nested-2.c
#include
#include
typedef int aligned __attribute__((aligned(16)));
int global;
void
check (int *i)
{
*i = 20;
if int) i) & (__alignof__(aligned) - 1)) != 0)
{
printf("\nUnalign address (%d): %p!\n",
__alignof__(aligned), i);
abort ();
}
}
void
foo (void)
{
aligned jj;
void bar ()
{
jj = -20;
}
jj = 0;
bar ();
check (&jj);
}
int
main()
{
foo ();
return 0;
}
> gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/wlin5/gcc/src-daily/configure
--enable-languages=c,c++,fortran --disable-bootstrap
Thread model: posix
gcc version 4.3.0 20080106 (experimental) [trunk revision 131347] (GCC)
> gcc -m32 -o nested-2.exe nested-2.c
> ./nested-2.exe
Unalign address (16): 0xffa137dc!
Aborted
--
Summary: Misalign stack variable referenced by nested function
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Joey dot ye at intel dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34921
[Bug fortran/34896] [4.3 Regression] libgomp.fortran/reduction5.f90
--- Comment #4 from pault at gcc dot gnu dot org 2008-01-22 06:08 --- I think that you will find that has gone, as promised. Thanks Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34896
[Bug c++/34919] ICE with invalid use of parameter pack
--- Comment #1 from steven at gcc dot gnu dot org 2008-01-22 06:06 --- ...and does not ICE with version...? -- steven at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3 regression] ICE with |ICE with invalid use of |invalid use of parameter|parameter pack |pack| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34919
[Bug c++/34920] Members in nameless union
--- Comment #2 from extronus at gmail dot com 2008-01-22 06:04 ---
more simplified
-
template
struct base
{
float a;
};
template
class derv : public base
{
void der_funk()
{
a = 0;
}
};
while this one works
--
template
struct base
{
float a;
};
template
class derv : public base
{
void der_funk()
{
a = 0;
}
};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34920
[Bug fortran/34896] [4.3 Regression] libgomp.fortran/reduction5.f90
--- Comment #3 from pault at gcc dot gnu dot org 2008-01-22 06:02 --- Subject: Bug 34896 Author: pault Date: Tue Jan 22 06:01:54 2008 New Revision: 131712 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131712 Log: 2008-01-22 Paul Thomas <[EMAIL PROTECTED]> PR fortran/34896 * module.c (read_module): Set use_rename attribute. 2008-01-22 Paul Thomas <[EMAIL PROTECTED]> PR fortran/34896 * gfortran.dg/use_rename_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/use_rename_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34896
[Bug c++/34917] [4.2/4.3 regression] ICE with const vector
--- Comment #2 from cnstar9988 at gmail dot com 2008-01-22 06:01 ---
Confirmed gcc 4.2.2.
test.cc
=
const int i __attribute((vector_size(8))) = {};
int main(int argc, char **argv)
{
return 0;
}
=
test.cc:1: internal compiler error: in start_decl, at cp/decl.c:4018
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34917
[Bug preprocessor/34695] Preprocessor warning->error conversion from -Werror is silent
--- Comment #8 from manu at gcc dot gnu dot org 2008-01-22 05:52 --- (In reply to comment #7) > Created an attachment (id=14994) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14994&action=view) [edit] > gcc-cpp-Werror-message.patch > > de-obfuscate the pedwarn code path > Hi, Ed, not sure whether you know that for us to be able to accept your patch, you need a copyright assignment form with the FSF: http://gcc.gnu.org/contribute.html#legal -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34695
[Bug c++/25701] gcc.texi missing @direntry for g++
-- bje at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bje at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-01-29 20:24:26 |2008-01-22 05:35:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25701
[Bug fortran/34876] Can't read/write array sections with negative stride not specified
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-01-22 05:27 --- Changing summary to better reflect what is wrong. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Summary|can't read zero length array|Can't read/write array |sections|sections with negative ||stride not specified http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34876
[Bug c++/34920] Members in nameless union
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-22 05:11 ---
This is expect behavior as o is not dependent so it has to be looked up at
parse time and the parser does not look at dependent base classes for finding
symbols.
Doing:
void der_funk(TYPE v) {this->o[0] = v;}
Fixes the code and allows for the code to be compiled correctly.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34920
[Bug c++/34920] New: Members in nameless union
Members in nameless union defined in template base class cannot be accessed by
template derived class. Methods in base class can access members.
Tried on 3.4.5 (mingw) and 4.1.2 (gentoo)
Simplified code :
template
class base
{
public :
typedef TYPE arrayType1[4];
typedef TYPE arrayType2[2][2];
union {
arrayType1 o; ///< One dimensional array
arrayType2 t; ///< Two dimensional array
struct
{
TYPE m11; TYPE m12; TYPE m13; TYPE m14;
};
};
void base_funk()
{
o[0] = 0;
}
};
template
class derived : public base
{
public :
void der_funk(TYPE v) {o[0] = v;}
};
--
Summary: Members in nameless union
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: extronus at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34920
[Bug bootstrap/34818] --with-gmp overrides --with-mpfr
--- Comment #1 from bje at gcc dot gnu dot org 2008-01-22 04:57 --- I agree with your reasoning for the easy fix. I'll post a patch and we'll see if it is accepted. If not, there is a fair bit more work involved to split the gmplibs variable into two new variables. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34818
[Bug c++/34196] [4.3 Regression] uninitialized variable warning in dead exception region
--- Comment #4 from jason at gcc dot gnu dot org 2008-01-22 04:54 --- Subject: Bug 34196 Author: jason Date: Tue Jan 22 04:53:33 2008 New Revision: 131710 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131710 Log: PR c++/34196 * tree.h (TRY_CATCH_IS_CLEANUP): New macro. * cp/decl.c (wrap_cleanups_r): Set TRY_CATCH_IS_CLEANUP. * tree-eh.c (honor_protect_cleanup_actions): Strip TRY_CATCH_EXPR if it is set. Added: trunk/gcc/testsuite/g++.dg/eh/init-temp2.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/tree-eh.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34196
[Bug bootstrap/34818] --with-gmp overrides --with-mpfr
-- bje at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bje at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-22 04:38:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34818
[Bug c++/33959] [4.1/4.2/4.3 Regression] ICE in instantiate_class_template, at cp/pt.c:6649
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-10-31 15:41:24 |2008-01-22 04:12:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33959
[Bug c/34911] [4.1/4.2/4.3 regression] ICE with vectors of bool
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-22 03:59 --- THis also happens with the C front-end, using -Dbool=_Bool . Confirmed. 4.0.1 (at least without checking) accepted this in C mode. I think we should reject bool vectors anyways. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|c++ |c Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-22 03:59:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34911
[Bug c++/34917] [4.2/4.3 regression] ICE with const vector
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-22 03:53 --- This is a blocker for me. Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |blocker Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-22 03:53:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34917
[Bug target/545] -std=c89 defines macros it shouldn't
--- Comment #16 from bje at gcc dot gnu dot org 2008-01-22 03:51 --- Not much has changed. For r131688: ./ptx4.h ./sol2.h ./svr4.h ./cris/aout.h ./rs6000/aix53.h ./rs6000/sysv4.h ./rs6000/aix51.h ./rs6000/aix.h ./rs6000/aix52.h ./rs6000/aix43.h ./rs6000/aix41.h ./i386/sco5.h ./i386/cygwin.h -- bje at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-09-24 17:13:22 |2008-01-22 03:51:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=545
[Bug fortran/34907] valgrind error indication from testsuite trans-types.c: gfc_typenode_for_spec
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-01-22 03:30 --- I would commit the parse.c line in comment #3 as OBVIOUS and get that out of the way. This looks like a pointer casting problem similar to recent patches I made for the cshift optional dummy problems. (sigh) I will look around a bit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34907
[Bug target/15951] m68k-*-elf doesn't allow --with-cpu= in the configure script
--- Comment #3 from bje at gcc dot gnu dot org 2008-01-22 03:22 --- This now works on mailine: ./xgcc -B. -v foo.c Reading specs from ./specs Target: m68k-elf Configured with: /home/bje/source/gcc-trunk/configure --target=m68k-elf --enable-languages=c --disable-mutilib --with-cpu=cpu32 [...] ./cc1 -quiet -v -iprefix /scratch/bje/m68k/gcc/../lib/gcc/m68k-elf/4.3.0/ -isystem ./include -isystem ./include-fixed foo.c -quiet -dumpbase foo.c -mcpu=cpu32 -auxbase foo -version -o /tmp/cczoPnzM.s I propose that since it is highly unlikely to ever be fixed in 3.4, that we close this bug. OK? -- bje at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15951
[Bug fortran/34899] Continuation lines with not recognized
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-01-22 03:12 --- With Tobias patch, the example code in comment 4 compiles with or without a tab preceding the 1 digit. It also works with 0 to 5 spaces preceding the tab and fails with anything between the tab and the first digit 1. So I think the patch is safe. Call it a legacy feature, it gives a warning with -std=f95 or -pedantic (rant) That being said, With all the brain power out there writing extremely complex code, you would think some one would just right the simple conversion program and get rid of all the tabs and handle the special case once and for all. It ain't that hard folks to fix your damn code. :) whooo! that felt good. Of course this patch is only about 15 lines of code. Maybe I should post a Fortran -std=f95 compliant program on the wiki, Call it "TabStripper.f" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34899
[Bug fortran/34875] read into vector-valued section doesn't transfer any values
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-01-22 02:46 --- Unfamiliar with this part of front end involved. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jvdelisle at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34875
[Bug fortran/34876] can't read zero length array sections
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-01-22 02:44 --- Front End does set default stride to one and does not check fo rthe case of a negative stride. Unassigning since it is in unfamiliar territory for me. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||32834 nThis|| AssignedTo|jvdelisle at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34876
[Bug target/19490] PowerPC back end ignores SPE command-line options
-- bje at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bje at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-22 01:05:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19490
[Bug target/34422] Bootstrap error with --enable-fixed-point
--- Comment #1 from bje at gcc dot gnu dot org 2008-01-22 00:58 --- Confirmed with today' r131705. The --with-arch option seems to have no involvement here. -- bje 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-22 00:58:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34422
[Bug preprocessor/34695] Preprocessor warning->error conversion from -Werror is silent
--- Comment #7 from ed at catmur dot co dot uk 2008-01-22 00:58 --- Created an attachment (id=14994) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14994&action=view) gcc-cpp-Werror-message.patch de-obfuscate the pedwarn code path -- ed at catmur dot co dot uk changed: What|Removed |Added Attachment #14993|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34695
[Bug preprocessor/34695] Preprocessor warning->error conversion from -Werror is silent
--- Comment #6 from ed at catmur dot co dot uk 2008-01-22 00:55 --- Created an attachment (id=14993) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14993&action=view) gcc-cpp-Werror-message.patch Try to handle system-header and inhibit conditions/flags correctly. -- ed at catmur dot co dot uk changed: What|Removed |Added Attachment #14981|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34695
[Bug target/34916] gcc.c-torture/execute/pr27364.c fails with -O1, -O2 and -Os
--- Comment #3 from hutchinsonandy at aim dot com 2008-01-22 00:52 --- Assembler of short testcase. Constant load (11L) missing 16.Ltext0: 17.global f2 19f2: 20.LFB2: 21.LM1: 22.LVL0: 23/* prologue: function */ 24/* frame size = 0 */ 25.LM2: 26 0E94 call __mulsi3 27.LVL1: 28/* epilogue start */ 29.LM3: 30 0004 0895 ret 31.LFE2: 57.Letext0: DEFINED SYMBOLS -- hutchinsonandy at aim dot com changed: What|Removed |Added CC||hutchinsonandy at aim dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34916
[Bug target/34916] gcc.c-torture/execute/pr27364.c fails with -O1, -O2 and -Os
--- Comment #2 from hutchinsonandy at aim dot com 2008-01-22 00:26 ---
Created an attachment (id=14992)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14992&action=view)
dce pass RTL dump file (bfore combine)
Posted two RTL dump file of smaller testcase:
long f2(long number_of_digits_to_use)
{
return ( number_of_digits_to_use * 11L ) ;
}
This faile GCC head 4.3.0 of 13/12/2007
Combine decide load of constant is not needed. Seem to happen after combine
tries combining load with multiply (ie multiply by constant).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34916
[Bug c++/34919] [4.3 regression] ICE with invalid use of parameter pack
-- 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=34919
[Bug c++/34919] New: [4.3 regression] ICE with invalid use of parameter pack
The following invalid testcase triggers an ICE on mainline:
=
template struct A
{
static void foo()
{
int i = N;
}
};
void bar()
{
A<0>::foo();
}
=
bug.cc: In static member function 'static void A::foo() [with int ...N =
0]':
bug.cc:11: instantiated from here
bug.cc:5: internal compiler error: in gimplify_expr, at gimplify.c:6108
Please submit a full bug report, [etc.]
--
Summary: [4.3 regression] ICE with invalid use of parameter pack
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
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=34919
[Bug target/34916] gcc.c-torture/execute/pr27364.c fails with -O1, -O2 and -Os
--- Comment #1 from hutchinsonandy at aim dot com 2008-01-22 00:23 --- Created an attachment (id=14991) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14991&action=view) Combine pass RTL dump file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34916
[Bug c++/34918] [4.1/4.2/4.3 regression] Broken diagnostic: 'vector_cst' not supported by dump_expr
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34918
[Bug c++/34918] New: [4.1/4.2/4.3 regression] Broken diagnostic: 'vector_cst' not supported by dump_expr
A broken diagnostic is issued for the following testcase since GCC 4.0.2: = int v __attribute((vector_size(8))); bool b = !(v - v); = bug.cc:3: error: could not convert '#'vector_cst' not supported by dump_expr#' to 'bool' bug.cc:3: error: in argument to unary ! -- Summary: [4.1/4.2/4.3 regression] Broken diagnostic: 'vector_cst' not supported by dump_expr Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic, monitored Severity: normal Priority: P3 Component: c++ 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=34918
[Bug c++/34917] [4.2/4.3 regression] ICE with const vector
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34917
[Bug c++/34917] New: [4.2/4.3 regression] ICE with const vector
The following valid code snippet triggers an ICE since GCC 4.2.0:
=
const int i __attribute((vector_size(8))) = {};
=
bug.cc:1: internal compiler error: in start_decl, at cp/decl.c:4130
Please submit a full bug report, [etc.]
--
Summary: [4.2/4.3 regression] ICE with const vector
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c++
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=34917
[Bug target/34916] New: gcc.c-torture/execute/pr27364.c fails with -O1, -O2 and -Os
This test case fails with latest gcc 4.3.0. The test assumes 32 bit integers,
but even after changing the constants to long, it produces incorrect results.
With -O2 we get this:
int f(unsigned number_of_digits_to_use)
{
if (number_of_digits_to_use > 1294)
206:65 e0 ldir22, 0x05; 5
208:8f 30 cpir24, 0x0F; 15
20a:96 07 cpcr25, r22
20c:c0 f4 brcc.+48 ; 0x23e
return 0;
return ((number_of_digits_to_use * 3321928L) / 100L + 1) /16;
20e:bc 01 movwr22, r24
210:80 e0 ldir24, 0x00; 0
212:90 e0 ldir25, 0x00; 0
214:0e 94 6c 06 call0xcd8; 0xcd8 <__mulsi3>
[...]
It "forgets" to load r18:r19:r20:r21 with 3321928 before calling __mulsi3.
--
Summary: gcc.c-torture/execute/pr27364.c fails with -O1, -O2 and
-Os
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pmarques at grupopie dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: avr-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34916
[Bug other/12618] core not cleaned up by 'make distclean'
--- Comment #3 from bje at gcc dot gnu dot org 2008-01-21 23:52 --- Patch posted to: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00975.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12618
[Bug fortran/34915] New: -std=f95 rejects len_trim() and index() in init expressions
See:
http://groups.google.fr/group/comp.lang.fortran/browse_thread/thread/60c6758faf1762ad
Test case by Al Greynolds:
module bug
character(*),dimension(3),parameter :: a=(/'a() ','b(,) ','c(,,)'/)
integer,dimension(3),parameter :: l=len_trim(a),i=index(a,'(')
end
integer,dimension(3),parameter :: l=len_trim(a),i=index(a,'(')
1
Error: Extension: Evaluation of nonstandard initialization expression at (1)
Works with g95 -std=f95, NAG f95, ifort.
>From the standard (Craig Dedo):
Constant expressions and initialization expressions are defined in section
7.1.6.1 of the Fortran 95 standard. "An initialization expression is a
constant
expression in which the exponentiation operation is permitted only with an
integer power, and each primary is ... " in one of 9 categories of thingos.
One
of these categories is:
"(4) An elemental intrinsic function reference of type integer or character
where each argument is an initialization expression of type integer or
character;".
The function INDEX is defined in section 13.14.47 and the function LEN_TRIM
is defined in section 13.14.55. Both of these are in the class of elemental
functions. Therefore, both should be allowed in initialization expressions.
--
Summary: -std=f95 rejects len_trim() and index() in init
expressions
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic
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=34915
[Bug other/12618] core not cleaned up by 'make distclean'
-- bje at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bje at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-02-20 18:39:58 |2008-01-21 23:38:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12618
[Bug bootstrap/32287] gas version style changed causes warnings with configure
--- Comment #13 from hjl dot tools at gmail dot com 2008-01-21 23:34 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00974.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32287
[Bug c++/34914] [4.1/4.2/4.3 regression] Broken diagnostic: 'offset_type' not supported by pp_c_type_specifier
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34914
[Bug c++/34914] New: [4.1/4.2/4.3 regression] Broken diagnostic: 'offset_type' not supported by pp_c_type_specifier
A broken diagnostic is issued for the following testcase since GCC 4.0.0:
struct A {};
void foo()
{
int A::* p __attribute((vector_size(8)));
p == 0;
}
bug.cc: In function 'void foo()':
bug.cc:6: error: invalid operands of types '#'offset_type' not supported by
pp_c_type_specifier#__vector__' and 'int' to binary 'operator=='
--
Summary: [4.1/4.2/4.3 regression] Broken diagnostic:
'offset_type' not supported by pp_c_type_specifier
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic, monitored
Severity: normal
Priority: P3
Component: c++
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=34914
[Bug c++/34913] [4.1/4.2/4.3 regression] ICE vector in template
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34913
[Bug c++/34913] New: [4.1/4.2/4.3 regression] ICE vector in template
The following (IMHO valid) code snippet triggers an ICE since GCC 4.0.0:
template struct A
{
int x[sizeof(T)] __attribute((vector_size(8)));
};
bug.cc:3: internal compiler error: tree check: did not expect class 'type',
have 'type' (template_type_parm) in contains_placeholder_p, at tree.c:2297
Please submit a full bug report, [etc.]
--
Summary: [4.1/4.2/4.3 regression] ICE vector in template
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c++
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=34913
[Bug middle-end/24573] g++: Internal error message while building openh323
--- Comment #5 from bje at gcc dot gnu dot org 2008-01-21 23:28 --- Can you please try building again with GCC 4.2? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24573
[Bug fortran/34907] valgrind error indication from testsuite trans-types.c: gfc_typenode_for_spec
--- Comment #4 from burnus at gcc dot gnu dot org 2008-01-21 23:26 --- I wonder whether the following makes sense; I think it does, but it does not seem to fix the problem :-( Index: decl.c === --- decl.c (Revision 131702) +++ decl.c (Arbeitskopie) @@ -1593,6 +1593,7 @@ variable_decl (int elem) sym->ts.derived = current_ts.derived; sym->ts.is_c_interop = current_ts.is_c_interop; sym->ts.is_iso_c = current_ts.is_iso_c; + sym->ts.f90_type = current_ts.f90_type; m = MATCH_YES; /* Check to see if we have an array specification. */ -- 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-21 23:26:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34907
[Bug other/22232] Bug in "fixproto" (missing escape)
-- bje at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bje at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-21 23:25:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22232
[Bug c++/34912] [4.1/4.2/4.3 regression] ICE with friend in local class
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34912
[Bug c++/34912] New: [4.1/4.2/4.3 regression] ICE with friend in local class
The following invalid code snippet triggers an ICE since GCC 4.1.2:
void foo()
{
struct A
{
friend void bar();
};
bar();
}
bug.cc: In function 'void foo()':
bug.cc:7: internal compiler error: in lookup_name_real, at
cp/name-lookup.c:4054
Please submit a full bug report, [etc.]
The code was wrongfully accepted before GCC 4.1.0, but correctly diagnosed in
GCC 4.1.0 and 4.1.1.
--
Summary: [4.1/4.2/4.3 regression] ICE with friend in local class
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
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=34912
[Bug c++/34824] [4.1/4.2/4.3 Regression] ICE with explicit copy constructor
--- Comment #5 from pcarlini at suse dot de 2008-01-21 23:23 --- Related to PR28475, then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34824
[Bug fortran/34871] Flavor VARIABLE vs. FUNCTION: Accepts invalid
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-01-21 23:23 --- And Pr34910. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34871
[Bug c++/34911] [4.1/4.2/4.3 regression] ICE with vectors of bool
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34911
[Bug c++/34911] New: [4.1/4.2/4.3 regression] ICE with vectors of bool
The following code snippet triggers an ICE since GCC 4.0.2:
bool foo() __attribute((vector_size(8)));
void bar()
{
foo() & foo();
}
bug.cc: In function 'void bar()':
bug.cc:5: internal compiler error: in same_scalar_type_ignoring_signedness, at
c-common.c:7203
Please submit a full bug report, [etc.]
I'm not sure whether the code is valid or not, GCC 3.4.[56] accepted it,
but GCC 4.0.[01] rejected it.
--
Summary: [4.1/4.2/4.3 regression] ICE with vectors of bool
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c++
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=34911
[Bug c++/34573] [4.3 Regression] ICE with nested class in template
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-01-08 22:30:04 |2008-01-21 23:16:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34573
[Bug fortran/34910] New: ICE on invalid assignments in doubly-contained functions
$> cat ice.f90 MODULE foo CONTAINS INTEGER FUNCTION f() f = 42 CONTAINS LOGICAL FUNCTION f1() f1 = .TRUE. END FUNCTION LOGICAL FUNCTION f2() f1 = .FALSE. ! <--- END FUNCTION END FUNCTION END MODULE $> gfortran-svn -Wall -c ice.f90 ice.f90: In function 'f2': ice.f90:6: internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:483 $> gfortran-svn -v gcc version 4.3.0 20080116 (experimental) Problem seems to be in expr.c (gfc_check_assign):2690. If the containing namespace is a function, the appropriate tests are skipped. -- Summary: ICE on invalid assignments in doubly-contained functions Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34910
[Bug fortran/34907] valgrind error indication from testsuite trans-types.c: gfc_typenode_for_spec
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-21 23:11 --- Move to Fortran. The problem seems to be: if (spec->f90_type == BT_VOID) which is for some reason not initialized. With openSUSE's 4.3.0 20080102 I don't see it. I actually do not see how this comes as gfc_clear_ts sets it. In any case the following is a useful patch: Index: parse.c === --- parse.c (Revision 131702) +++ parse.c @@ -2189,7 +2189,7 @@ loop: gfc_current_block ()->ts.kind = 0; /* Keep the derived type; if it's bad, it will be discovered later. */ - if (!(ts->type = BT_DERIVED && ts->derived)) + if (!(ts->type == BT_DERIVED && ts->derived)) ts->type = BT_UNKNOWN; } -- burnus at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |fortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34907
[Bug c/34873] varasm.c:3387: warning: right shift count >= width of type
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-21 23:08 ---
This is the code:
const int shift = sizeof (hashval_t) * CHAR_BIT;
const int n = sizeof (HOST_WIDE_INT) / sizeof (hashval_t);
int i;
h ^= (hashval_t) hwi;
for (i = 1; i < n; ++i)
{
hwi >>= shift;
h ^= (hashval_t) hwi;
}
This code is dead if sizeof (HOST_WIDE_INT) == sizeof (hashval_t).
This is a bug in the 4.1.2 you are using and not in the current sources.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|middle-end |c
Version|4.3.0 |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34873
[Bug c++/34846] [4.3 regression] ICE on STL container iterator copy
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-01-18 09:33:56 |2008-01-21 23:00:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34846
[Bug regression/33928] [4.3 Regression] 22% performance slowdown from 4.2.2 to 4.3.0 in floating-point code
--- Comment #24 from lucier at math dot purdue dot edu 2008-01-21 22:43 --- Subject: Re: [4.3 Regression] 22% performance slowdown from 4.2.2 to 4.3.0 in floating-point code On Jan 21, 2008, at 2:21 PM, ubizjak at gmail dot com wrote: > It is not possible to create an executable from direct.i. That's correct, sorry. > Could you attach the source that can be used to create the executable? Here are instructions on how to build and test a modified version of Gambit, from which I derived direct.i. Download the file http://www.math.purdue.edu/~lucier/gcc/test-files/bugzilla/33928/ gambc-v4_1_2.tgz Build it with the following commands: > tar zxf gambc-v4_1_2.tgz > cd gambc-v4_1_2 > ./configure CC='/pkgs/gcc-mainline/bin/gcc -save-temps' > make -j If you want to recompile the source after reconfiguring, do > make mostlyclean not 'make clean', unfortunately. Then test it with > gsi/gsi -e '(define a (time (expt 3 1000)))(define b (time (* a > a)))' The output ends with something like > (time (##bignum.make (##fixnum.quotient result-length > (##fixnum.quotient ##bignum.adigit-width ##bignum.fdigit-width)) #f > #f)) > 4 ms real time > 5 ms cpu time (3 user, 2 system) > no collections > 3962448 bytes allocated > 968 minor faults > no major faults > (time (##make-f64vector (##fixnum.* two^n 2))) > 5 ms real time > 5 ms cpu time (1 user, 4 system) > 1 collection accounting for 5 ms real time (1 user, 4 system) > 33554464 bytes allocated > 59 minor faults > no major faults > (time (make-w (##fixnum.- log-two^n 1))) > 30 ms real time > 31 ms cpu time (17 user, 14 system) > no collections > 16810144 bytes allocated > 4097 minor faults > no major faults > (time (make-w-rac log-two^n)) > 28 ms real time > 28 ms cpu time (16 user, 12 system) > no collections > 16826272 bytes allocated > 4097 minor faults > no major faults > (time (bignum->f64vector-rac x a)) > 45 ms real time > 45 ms cpu time (20 user, 25 system) > no collections > -16 bytes allocated > 8192 minor faults > no major faults > (time (componentwise-rac-multiply a rac-table)) > 26 ms real time > 26 ms cpu time (26 user, 0 system) > no collections > -16 bytes allocated > no minor faults > no major faults > (time (direct-fft-recursive-4 a table)) > 445 ms real time > 445 ms cpu time (445 user, 0 system) > no collections > 64 bytes allocated > no minor faults > no major faults > (time (componentwise-complex-multiply a a)) > 24 ms real time > 24 ms cpu time (24 user, 0 system) > no collections > -16 bytes allocated > no minor faults > no major faults > (time (inverse-fft-recursive-4 a table)) > 418 ms real time > 418 ms cpu time (418 user, 0 system) > no collections > 64 bytes allocated > no minor faults > no major faults > (time (componentwise-rac-multiply-conjugate a rac-table)) > 26 ms real time > 26 ms cpu time (26 user, 0 system) > no collections > -16 bytes allocated > no minor faults > no major faults > (time (bignum<-f64vector-rac a result result-length)) > 108 ms real time > 108 ms cpu time (108 user, 0 system) > no collections > 112 bytes allocated > no minor faults > no major faults > (time (* a a)) > 1170 ms real time > 1170 ms cpu time (1105 user, 65 system) > 1 collection accounting for 5 ms real time (1 user, 4 system) > 71266896 bytes allocated > 17413 minor faults > no major faults The time for the routine in direct.i is the time reported for direct- fft-recursive-4: > (time (direct-fft-recursive-4 a table)) > 445 ms real time > 445 ms cpu time (445 user, 0 system) > no collections > 64 bytes allocated > no minor faults > no major faults The name of the routine in the .i and .s files is ___H_direct_2d_fft_2d_recursive_2d_4. By the way, ___H_inverse_2d_fft_2d_recursive_2d_4 is a similar routine implementing the inverse fft, which, for some reason, goes faster than the direct (forward) fft. Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug fortran/34871] Flavor VARIABLE vs. FUNCTION: Accepts invalid
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-01-21 22:11 --- There are multiple issues with function names, i.e. where a function symbol is picked up which shouldn't. See PR34714 for another example. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34871
[Bug middle-end/34909] valgrind error indication from testsuite c-pch.c: c_common_write_pch
--- Comment #1 from ismail at pardus dot org dot tr 2008-01-21 22:06 --- Used svn revision 131650. -- ismail at pardus dot org dot tr changed: What|Removed |Added GCC host triplet||i686-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34909
[Bug middle-end/34909] New: valgrind error indication from testsuite c-pch.c: c_common_write_pch
FAIL: ./interface-1.h -O0 -g (test for excess errors) Excess errors: ==32267== Invalid read of size 1 ==32267==at 0x4024F08: memcpy (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==32267==by 0x80B8E4E: c_common_write_pch (c-pch.c:212) ==32267==by 0x80617C3: pop_file_scope (c-decl.c:922) ==32267==by 0x80AE38E: c_common_parse_file (c-opts.c:1286) ==32267==by 0x82D79EE: compile_file (toplev.c:1042) ==32267==by 0x82D92E2: do_compile (toplev.c:2251) ==32267==by 0x82D9344: toplev_main (toplev.c:2283) ==32267==by 0x80CE6A9: main (main.c:35) ==32267== Address 0x460f53c is not stack'd, malloc'd or (recently) free'd -- Summary: valgrind error indication from testsuite c-pch.c: c_common_write_pch Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ismail at pardus dot org dot tr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34909
[Bug middle-end/34908] New: valgrind error indication from testsuite hashtab.c : htab_hash_string
FAIL: gfortran.dg/do_3.F90 -O3 -g (test for excess errors) Excess errors: ==6073== Invalid read of size 1 ==6073==at 0x870B847: htab_hash_string (hashtab.c:812) ==6073==by 0x8196A99: lookup_filename (dwarf2out.c:14304) ==6073==by 0x8191935: add_src_coords_attributes (dwarf2out.c:11359) ==6073==by 0x81919FE: add_name_and_src_coords_attributes (dwarf2out.c:11376) ==6073==by 0x81935B4: gen_subprogram_die (dwarf2out.c:12376) ==6073==by 0x8196109: gen_decl_die (dwarf2out.c:13901) ==6073==by 0x81968ED: dwarf2out_decl (dwarf2out.c:14218) ==6073==by 0x81931AE: dwarf2out_abstract_function (dwarf2out.c:12236) ==6073==by 0x84BAEB8: expand_call_inline (tree-inline.c:2874) ==6073==by 0x84BAFA2: gimple_expand_calls_inline (tree-inline.c:2910) ==6073==by 0x84BB2D8: optimize_inline_calls (tree-inline.c:3003) ==6073==by 0x849E44F: apply_inline (ipa-inline.c:1598) ==6073== Address 0x424fa38 is 0 bytes inside a block of size 90 free'd ==6073==at 0x4022F82: free (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==6073==by 0x80BD16B: preprocessor_line (scanner.c:1412) ==6073==by 0x80BD585: load_file (scanner.c:1566) ==6073==by 0x80BD8A5: gfc_new_file (scanner.c:1680) ==6073==by 0x80D24ED: gfc_init (f95-lang.c:290) ==6073==by 0x8314354: lang_dependent_init (toplev.c:2128) ==6073==by 0x8314585: do_compile (toplev.c:2250) ==6073==by 0x83145F0: toplev_main (toplev.c:2283) ==6073==by 0x811D011: main (main.c:35) ==6073==· ==6073== Invalid read of size 1 ==6073==at 0x4024CC3: strcmp (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==6073==by 0x870B4E1: htab_find_slot_with_hash (hashtab.c:634) ==6073==by 0x8196ABA: lookup_filename (dwarf2out.c:14304) ==6073==by 0x8191935: add_src_coords_attributes (dwarf2out.c:11359) ==6073==by 0x81919FE: add_name_and_src_coords_attributes (dwarf2out.c:11376) ==6073==by 0x8192CBD: gen_formal_parameter_die (dwarf2out.c:12063) ==6073==by 0x81963AA: gen_decl_die (dwarf2out.c:13985) ==6073==by 0x8193A1E: gen_subprogram_die (dwarf2out.c:12540) ==6073==by 0x8196109: gen_decl_die (dwarf2out.c:13901) ==6073==by 0x81968ED: dwarf2out_decl (dwarf2out.c:14218) ==6073==by 0x81931AE: dwarf2out_abstract_function (dwarf2out.c:12236) ==6073==by 0x84BAEB8: expand_call_inline (tree-inline.c:2874) ==6073== Address 0x424fa38 is 0 bytes inside a block of size 90 free'd ==6073==at 0x4022F82: free (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==6073==by 0x80BD16B: preprocessor_line (scanner.c:1412) ==6073==by 0x80BD585: load_file (scanner.c:1566) ==6073==by 0x80BD8A5: gfc_new_file (scanner.c:1680) ==6073==by 0x80D24ED: gfc_init (f95-lang.c:290) ==6073==by 0x8314354: lang_dependent_init (toplev.c:2128) ==6073==by 0x8314585: do_compile (toplev.c:2250) ==6073==by 0x83145F0: toplev_main (toplev.c:2283) ==6073==by 0x811D011: main (main.c:35) Used svn revision 131650. -- Summary: valgrind error indication from testsuite hashtab.c : htab_hash_string Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ismail at pardus dot org dot tr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34908
[Bug libstdc++/33486] parallel v3: functions not in right namespace
--- Comment #4 from bangerth at dealii dot org 2008-01-21 22:01 --- I don't know. What namespace are the parallel containers in, and what namespace are the parallel algorithms in? W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33486
[Bug middle-end/34907] valgrind error indication from testsuite trans-types.c: gfc_typenode_for_spec
--- Comment #2 from ismail at pardus dot org dot tr 2008-01-21 22:00 --- Also this part seems to apply too: ==29085==· ==29085== Conditional jump or move depends on uninitialised value(s) ==29085==at 0x811A4B9: gfc_typenode_for_spec (trans-types.c:848) ==29085==by 0x810041F: gfc_conv_intrinsic_conversion (trans-intrinsic.c:265) ==29085==by 0x8108A81: gfc_conv_intrinsic_function (trans-intrinsic.c:3822) ==29085==by 0x80FCE9D: gfc_conv_function_expr (trans-expr.c:3033) ==29085==by 0x80FE23B: gfc_conv_expr (trans-expr.c:3537) ==29085==by 0x80FE365: gfc_conv_expr_val (trans-expr.c:3590) ==29085==by 0x80EA952: gfc_conv_expr_descriptor (trans-array.c:4805) ==29085==by 0x80EB554: gfc_conv_array_parameter (trans-array.c:5102) ==29085==by 0x80FB8C1: gfc_conv_function_call (trans-expr.c:2464) ==29085==by 0x810370F: gfc_conv_intrinsic_funcall (trans-intrinsic.c:1641) ==29085==by 0x8108811: gfc_conv_intrinsic_function (trans-intrinsic.c:3727) ==29085==by 0x80FCE9D: gfc_conv_function_expr (trans-expr.c:3033) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34907
[Bug middle-end/34907] valgrind error indication from testsuite trans-types.c: gfc_typenode_for_spec
--- Comment #1 from ismail at pardus dot org dot tr 2008-01-21 21:59 --- Used svn revision 131650. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34907
[Bug middle-end/34907] New: valgrind error indication from testsuite trans-types.c: gfc_typenode_for_spec
Valgrind shows, FAIL: gfortran.dg/char_cshift_1.f90 -O0 (test for excess errors) Excess errors: ==28334== Conditional jump or move depends on uninitialised value(s) ==28334==at 0x811A4B9: gfc_typenode_for_spec (trans-types.c:848) ==28334==by 0x810041F: gfc_conv_intrinsic_conversion (trans-intrinsic.c:265) ==28334==by 0x8108A81: gfc_conv_intrinsic_function (trans-intrinsic.c:3822) ==28334==by 0x80FCE9D: gfc_conv_function_expr (trans-expr.c:3033) ==28334==by 0x80FE23B: gfc_conv_expr (trans-expr.c:3537) ==28334==by 0x80FE5E3: gfc_conv_expr_reference (trans-expr.c:3660) ==28334==by 0x80FB74B: gfc_conv_function_call (trans-expr.c:2428) ==28334==by 0x810370F: gfc_conv_intrinsic_funcall (trans-intrinsic.c:1641) ==28334==by 0x8108811: gfc_conv_intrinsic_function (trans-intrinsic.c:3727) ==28334==by 0x80FCE9D: gfc_conv_function_expr (trans-expr.c:3033) ==28334==by 0x80FE23B: gfc_conv_expr (trans-expr.c:3537) ==28334==by 0x80E42C9: gfc_add_loop_ss_code (trans-array.c:1902) -- Summary: valgrind error indication from testsuite trans-types.c: gfc_typenode_for_spec Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ismail at pardus dot org dot tr GCC host triplet: i686-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34907
[Bug bootstrap/32287] gas version style changed causes warnings with configure
--- Comment #12 from hjl dot tools at gmail dot com 2008-01-21 21:57 --- (In reply to comment #11) > Subject: Re: gas version style changed causes > warnings with configure > > On Mon, Jan 21, 2008 at 09:43:09PM -, hjl dot tools at gmail dot com > wrote: > > The second line isn't needed. I checked the following versions: > > > > ./check "GNU ld version 2.17.50.0.6-5.fc6 20061020" > > ./check "GNU ld version 2.17.50.0.12-4 20070128" > > ./check "GNU ld version 2.15.92.0.2 20040927" > > ./check "GNU ld (GNU Binutils) 2.18.50.20070913" > > ./check "GNU ld (Linux/GNU Binutils) 2.18.50.0.1.20070906" > > ./check "GNU ld (GNU Binutils) 2.17.50.20070726-12 (SUSE Linux)" > > ./check "GNU assembler (GNU Binutils for Debian) 2.17.50.20070426" > > > > and they work fine. Do you have more to add? > > It will fail on any line that contains xx.yy after the binutils > version. Didn't that used to happen? It worked on binutils 2.9.1, which was released in Feb, 1999. > If not we can remove basically the entire test. Once the first > pattern matches the rest is mostly irrelevant. Maybe they are irrelevant. Can you find a binutils which fails the current linker version test? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32287
[Bug ada/33457] Renaming in context of ragged array
--- Comment #2 from anhvofrcaus at gmail dot com 2008-01-21 21:54 --- This problem does not occur in gcc-4.3-20080118. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33457
[Bug bootstrap/32287] gas version style changed causes warnings with configure
--- Comment #11 from drow at gcc dot gnu dot org 2008-01-21 21:46 --- Subject: Re: gas version style changed causes warnings with configure On Mon, Jan 21, 2008 at 09:43:09PM -, hjl dot tools at gmail dot com wrote: > The second line isn't needed. I checked the following versions: > > ./check "GNU ld version 2.17.50.0.6-5.fc6 20061020" > ./check "GNU ld version 2.17.50.0.12-4 20070128" > ./check "GNU ld version 2.15.92.0.2 20040927" > ./check "GNU ld (GNU Binutils) 2.18.50.20070913" > ./check "GNU ld (Linux/GNU Binutils) 2.18.50.0.1.20070906" > ./check "GNU ld (GNU Binutils) 2.17.50.20070726-12 (SUSE Linux)" > ./check "GNU assembler (GNU Binutils for Debian) 2.17.50.20070426" > > and they work fine. Do you have more to add? It will fail on any line that contains xx.yy after the binutils version. Didn't that used to happen? If not we can remove basically the entire test. Once the first pattern matches the rest is mostly irrelevant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32287
[Bug bootstrap/32287] gas version style changed causes warnings with configure
--- Comment #10 from hjl dot tools at gmail dot com 2008-01-21 21:43 --- (In reply to comment #9) > > HJ, Richi, I can find a lot of confused versions of HJ's patch in that thread, > which starts here: > http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01170.html It is a good idea. > Nowhere can I find the actual approval. The only version which was approved > was safe, but the patch as applied is unsafe. If you put a .* there, then it > will match any "xx.yy" string anywhere in the version string, including after > the binutils version! This does not mess up on --with-pkgversion on new > versions of binutils but only because sed will use the shorter match, and the > binutils version comes second. > > + -e 's,^.*[ ]\([0-9][0-9]*\.[0-9][0-9]*.*\)$,\1,p' \ > -e 's,^.*[ ]\([0-9][0-9]*\.[0-9][0-9]*\)[ ].*$,\1,p' \ > > Note that second line will never match now. The second line isn't needed. I checked the following versions: ./check "GNU ld version 2.17.50.0.6-5.fc6 20061020" ./check "GNU ld version 2.17.50.0.12-4 20070128" ./check "GNU ld version 2.15.92.0.2 20040927" ./check "GNU ld (GNU Binutils) 2.18.50.20070913" ./check "GNU ld (Linux/GNU Binutils) 2.18.50.0.1.20070906" ./check "GNU ld (GNU Binutils) 2.17.50.20070726-12 (SUSE Linux)" ./check "GNU assembler (GNU Binutils for Debian) 2.17.50.20070426" and they work fine. Do you have more to add? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32287
[Bug c++/28460] [4.0/4.1 Regression] g++ emits bogus namespace DIE
--- Comment #16 from drow at gcc dot gnu dot org 2008-01-21 21:00 --- I don't care about 4.0/4.1 at this date. -- drow at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|drow at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28460
[Bug debug/27473] [4.0/4.1 Regression] g++.dg/other/unused1.C and gcc.dg/20060410.c fail on powerpc-darwin
--- Comment #5 from drow at gcc dot gnu dot org 2008-01-21 21:00 --- I don't care about 4.0/4.1 at this date. -- drow at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|drow at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27473
[Bug debug/23336] [4.0/4.1 Regression] enum constants not visible to gdb because of -feliminate-unused-debug-types
--- Comment #12 from drow at gcc dot gnu dot org 2008-01-21 20:59 --- I don't care about 4.0/4.1 at this date. -- drow at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|drow at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23336
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #47 from dominiq at lps dot ens dot fr 2008-01-21 20:55 --- > If you run the executable generated by: > -O3 -fipa-type-escape -fwhole-program -combine -fprofile-generate > w_prof_global_var.c -m64 > > is it fail or not? It does not fail: [ibook-dhum] bug/depend% /opt/gcc/gcc4.3w/bin/gcc -O3 -fipa-type-escape -fwhole-program -combine -fprofile-generate -m64 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/struct/w_prof_global_var.c [ibook-dhum] bug/depend% a.out [ibook-dhum] bug/depend% /opt/gcc/gcc4.3w/bin/gcc -O3 -fipa-type-escape -fwhole-program -combine -fprofile-use -m64 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/struct/w_prof_global_var.c [ibook-dhum] bug/depend% a.out So it seems that the failures come from the combination "-fipa-struct-reorg -fipa-type-escape -m64". If one option is missing in the triplet the test succeeds. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug c/32102] -Wall stomps on -Wstrict-overflow
--- Comment #11 from manu at gcc dot gnu dot org 2008-01-21 20:54 --- (In reply to comment #10) > This test case will give a warning with mainline with -Wstrict-overflow (aka > -Wstrict-overflow=2) but not with -Wall (which implies -Wstrict-overflow=1). > I think that testcase is structurally equivalent to the one I have included in my proposed (and unreviewed, ;-) patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32102
[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785
--- Comment #8 from jakub at gcc dot gnu dot org 2008-01-21 20:53 --- And, on these testcases that patch hasn't changed bad code generation into ICE, but good code generation into ICE, at least as far as I can eyeball the assembly, e.g. on the #c5 testcase with -Os and STACK_BOUNDARY redefinition in config/i386/darwin.h commented out I get: .text .globl _bar _bar: pushl %ebp movl%esp, %ebp subl$36, %esp movaps _v, %xmm0 movaps %xmm0, 12(%esp) movaps %xmm0, %xmm2 pushl $1 movaps %xmm0, %xmm1 call_foo addl$32, %esp leave ret .comm _v,16,4 .subsections_via_symbols which keeps the right stack alignment and passes the args in correct locations. So this is clearly a regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34621
[Bug middle-end/34852] [4.3 Regression] Revision 131576 miscompiled 178.galgel
--- Comment #16 from hjl dot tools at gmail dot com 2008-01-21 20:53 --- (In reply to comment #15) > Subject: Re: [4.3 Regression] Revision 131576 miscompiled 178.galgel > > > I tried -mpc64. It also works. > I would declare this a proof that it is extra preccision issue and > simply update testers to use -mpc64. It is what most of other compilers > do anyway and thus we would get more comparable scores. Thanks a lot for > testing it (I've scheduled same test for tonight, but you've beaten me. > I still will try if it works for -mfpmath=sse case too) > With the -march=native patch: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00969.html -funroll-loops -fpeel-loops -ffast-math -march=native -mtune=native -mfpmath=sse works for me. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34852
[Bug c++/27177] [4.1/4.2/4.3 Regression] ICE in build_simple_base_path, at cp/class.c:474
--- Comment #20 from crowl at google dot com 2008-01-21 20:49 --- Subject: Re: [4.1/4.2/4.3 Regression] ICE in build_simple_base_path, at cp/class.c:474 On 21 Jan 2008 02:00:07 -, mmitchel at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #19 from mmitchel at gcc dot gnu dot org 2008-01-21 02:00 > --- > Lawrence, thanks for looking into this. > > Was there any consensus on whether or not these are static_casts in this > context? The discussion didn't say so explicitly, but the obvious conclusion was that they were static_casts. > I'm guessing that the eventual resolution is going to be something like > saying that a cast is a static_cast even if the class is incomplete, so long > as the bases are known, but that such a static_cast can only be used > in an un-evaluated context. Is that correct? If I understand correctly, this issue can only arise in constant expressions. In any other context (as in default arguments or member bodies) the class would be complete, and hence the issue is moot. Is there something that you had in mind? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27177
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #46 from olga at il dot ibm dot com 2008-01-21 20:42 --- (In reply to comment #45) > > Sorry pursuing this issue, but let me completely understand it: when you run > > *with* profiling, there are two compilations and two executions. If you > > compile > > first with: > > > > -O3 -fipa-type-escape -fwhole-program -combine -fprofile-generate > > w_prof_global_var.c > > > > and run the generated executable, is it fail or not? > Sorry for beeing unclear. If I have done the compilation in 32 bit mode (the > default in my config), the generated executable run fine. Then I can use the > generated info to compile with -fprofile-use in 64 bit mode (-m64). gcc does > not complain about this dirty trick (I have no idea if it is supposed to work) > and produces an executable that fails to run. I do not know whether it's legal or not to use information collected by 32bits profiling for optimizations in 64bits, most likely it's not. But it's not what importent here. If you run the executable generated by: -O3 -fipa-type-escape -fwhole-program -combine -fprofile-generate w_prof_global_var.c -m64 is it fail or not? Olga -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug bootstrap/32287] gas version style changed causes warnings with configure
--- Comment #9 from drow at gcc dot gnu dot org 2008-01-21 20:41 --- Here's why I didn't remember the patch - I just checked it in, I didn't write it. 2007-08-23 Brian Sidebotham <[EMAIL PROTECTED]> * configure.ac (leb128): Modify sed statement to work with any binutils version string. * configure: Regenerate That version definitely handles: as_ver='GNU assembler (GNU Binutils for Debian) 2.18.20071027' It does not handle: as_ver='GNU assembler (Linux/GNU Binutils) 2.18.50.0.3.20071102' This version format is new and is not produced by the FSF binutils. I assume it's a result of HJ Lu's Linux binutils after a merge from FSF trunk. The ld_vers check up higher in the file was changed to handle the new version format on 2007-09-23. HJ, Richi, I can find a lot of confused versions of HJ's patch in that thread, which starts here: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01170.html Nowhere can I find the actual approval. The only version which was approved was safe, but the patch as applied is unsafe. If you put a .* there, then it will match any "xx.yy" string anywhere in the version string, including after the binutils version! This does not mess up on --with-pkgversion on new versions of binutils but only because sed will use the shorter match, and the binutils version comes second. + -e 's,^.*[ ]\([0-9][0-9]*\.[0-9][0-9]*.*\)$,\1,p' \ -e 's,^.*[ ]\([0-9][0-9]*\.[0-9][0-9]*\)[ ].*$,\1,p' \ Note that second line will never match now. The ld and as tests should be made uniform again but I think that we should go back to this one: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01170.html -- drow at gcc dot gnu dot org changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com, rguenther at suse dot ||de, bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32287
[Bug c/32102] -Wall stomps on -Wstrict-overflow
--- Comment #10 from ian at airs dot com 2008-01-21 20:40 ---
This test case will give a warning with mainline with -Wstrict-overflow (aka
-Wstrict-overflow=2) but not with -Wall (which implies -Wstrict-overflow=1).
void Alpha();
void Beta() {
int i;
for (i = 1; i > 0; i += i)
Alpha();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32102
[Bug driver/34904] -march=native doesn't work with multiple input files
--- Comment #1 from hjl dot tools at gmail dot com 2008-01-21 20:40 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00969.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||01/msg00969.html Component|target |driver http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34904
[Bug c++/34824] [4.1/4.2/4.3 Regression] ICE with explicit copy constructor
--- Comment #4 from jakub at gcc dot gnu dot org 2008-01-21 20:29 ---
Related testcase:
struct A;
struct B
{
B (A const &);
B (B &);
};
struct A
{
A (B) {}
};
B
f (A const &a)
{
return B (a);
}
which doesn't have explicit at all segfaults as well, also endless recursion.
In both cases the copy constructor can't be used,
so a conversion through A(B) constructor and then B(const A&) is attempted.
But that needs a temporary, so a B(const B &) copy constructor is needed and
we are back to the original problem.
If A's constructor is instead A (const B &) {}, then it compiles just fine
in both variants ( explicit B (const B &); and B (B &); ). So I guess we just
need to detect recursion here. I believe C++ will try only one hop through
some
other class' constructor, so perhaps just remembering one parent type would
be enough to prevent the recursion.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34824
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #45 from dominiq at lps dot ens dot fr 2008-01-21 20:26 --- > Sorry pursuing this issue, but let me completely understand it: when you run > *with* profiling, there are two compilations and two executions. If you > compile > first with: > > -O3 -fipa-type-escape -fwhole-program -combine -fprofile-generate > w_prof_global_var.c > > and run the generated executable, is it fail or not? Sorry for beeing unclear. If I have done the compilation in 32 bit mode (the default in my config), the generated executable run fine. Then I can use the generated info to compile with -fprofile-use in 64 bit mode (-m64). gcc does not complain about this dirty trick (I have no idea if it is supposed to work) and produces an executable that fails to run. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug bootstrap/33992] Building libstdc++-v3: include/limits: stray '\275' in program
--- Comment #11 from stefaan dot deroeck at gmail dot com 2008-01-21 20:18 --- I can reproduce with gcc 4.3 snapshot 20080118 -- stefaan dot deroeck at gmail dot com changed: What|Removed |Added CC||stefaan dot deroeck at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33992
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #44 from olga at il dot ibm dot com 2008-01-21 20:16 --- (In reply to comment #43) > >> They failed with -fprofile-generate (BTW they fail without -fprofile-*). > without! sorry > > If I understand you correctly, the executable of w_prof_global_var.c, > > compiled > > with -O3 -fipa-type-escape -fwhole-program -combine -fdump-ipa-all, fails on > > your system? > No, w_prof_global_var.c and friends pass without '-fipa-type-escape', but they > fail with > -O3 -fipa-struct-reorg -fwhole-program -combine -fipa-type-escape -m64 > due to a segfault (note that I don't know if '-fipa-struct-reorg > -fwhole-program -combine' makes sense without '-fipa-type-escape'). AFAICT > '-fdump-ipa-all' does not change the outcome: pass without > '-fipa-type-escape', > fail otherwise. The -fipa-type-escape flag activates the analysis pass, that does not optimize the code itself. The -fipa-struct-reorg relies on this analysis, and does nothing when it is not activated. Therefore the tests pass without ipa-type-escape. Sorry pursuing this issue, but let me completely understand it: when you run *with* profiling, there are two compilations and two executions. If you compile first with: -O3 -fipa-type-escape -fwhole-program -combine -fprofile-generate w_prof_global_var.c and run the generated executable, is it fail or not? > Could this problem be related to PR34621? I do not know. It can be checked by reverting the patch mentioned in comment #5 of this PR. Thank you, Olga -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug libgcj/34369] java.net.URI.relativize(URI) method returns incorrect results
--- Comment #6 from cvs-commit at developer dot classpath dot org 2008-01-21 20:11 --- Subject: Bug 34369 CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Tom Tromey 08/01/21 20:09:56 Modified files: . : ChangeLog java/net : URI.java Log message: 2008-01-21 Luciano Chavez <[EMAIL PROTECTED]> PR libgcj/34369: * java/net/URI.java (relativize): Check initial segment for trailing "/". CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpath&r1=1.9474&r2=1.9475 http://cvs.savannah.gnu.org/viewcvs/classpath/java/net/URI.java?cvsroot=classpath&r1=1.20&r2=1.21 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34369
[Bug libgcj/34369] java.net.URI.relativize(URI) method returns incorrect results
--- Comment #5 from tromey at gcc dot gnu dot org 2008-01-21 20:09 --- Subject: Bug 34369 Author: tromey Date: Mon Jan 21 20:08:38 2008 New Revision: 131701 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131701 Log: 2008-01-21 Luciano Chavez <[EMAIL PROTECTED]> PR libgcj/34369: * java/net/URI.java (relativize): Check initial segment for trailing "/". Modified: trunk/libjava/classpath/ChangeLog trunk/libjava/classpath/java/net/URI.java trunk/libjava/classpath/lib/java/net/URI.class -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34369
[Bug libgcj/34369] java.net.URI.relativize(URI) method returns incorrect results
--- Comment #4 from tromey at gcc dot gnu dot org 2008-01-21 20:09 --- Fixed on trunk. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34369
[Bug middle-end/31309] [4.1 regression] reads/writes past end of structure
--- Comment #26 from peeterj at ca dot ibm dot com 2008-01-21 20:00 --- (In reply to comment #25) > I don't plan to backport this to the 4.1 branch. > Thanks for both fixing this and backporting to 4.2! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31309
[Bug libgcj/34369] java.net.URI.relativize(URI) method returns incorrect results
--- Comment #3 from tromey at gcc dot gnu dot org 2008-01-21 20:00 --- I'm handling this. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-21 20:00:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34369
[Bug middle-end/31309] [4.1 regression] reads/writes past end of structure
--- Comment #25 from ebotcazou at gcc dot gnu dot org 2008-01-21 19:55 --- I don't plan to backport this to the 4.1 branch. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31309
[Bug middle-end/31309] [4.1 regression] reads/writes past end of structure
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-01-16 12:26:43 |2008-01-21 19:55:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31309
[Bug fortran/34899] Continuation lines with not recognized
--- Comment #4 from kargl at gcc dot gnu dot org 2008-01-21 19:24 --- (In reply to comment #3) > > Sorry, no! The code is non-conforming. The code should be fixed. > I downloaded the FITS package, and it's worse than I thought. Please don't unfix gfortran. This is valid fixed-form Fortran. c23456789012345678901234567890123456789012345678901234567890123456789012 program a integer , b, , dd, , f 1 f = 1 print *, f end program a If I understand correctly, you want to change gfortran to parse a leading tab as 5 spaces if it is followed by digit; otherwise, the leading tab is parsed as 6 spaces. OK, change the above program by replacing the 1 in column 5 to 'd'. This is again a valid fixed-form code. Now, replace the leading spaces with a tab. Do you expand the leading tab by 5 or 6 spaces? Seriously, the FITS code is invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34899
