[Bug fortran/20248] gfortran: intrinsics and std=f95, inconsistency with other compilers
--- Additional Comments From anlauf at hep dot tu-darmstadt dot de 2005-03-01 08:33 --- (In reply to comment #3) > Read the F2003 standard. > > 5.1.2.8INTRINSIC attribute > The INTRINSIC attribute confirms that a name is the specific name (13.6) or > generic name (13.5) of an intrinsic procedure. OK > When you set -std=f95, iargc is not an intrinsic procedure. So, when > you ask gfortran to *confirm* that iargc is an intrinsic procedure, > it tells that it isn't. The default behavior for gfortran is -std=gnu, > which makes iargc an intrinsic procedure. It is OK to reject iargc as an intrinsic procedure in the -std=f95 case during compilation, but the failure during linking when iargc is not specified as an intrinsic isn't. The Intel compiler (v8.1) resolves the problem as follows: - it does not change the name mapping/mangling when -stand=f95 is specified - it maps the recognized intrinsic iargc to for_iargc when it is requested as an intrinsic or not specified as external - it is mangled to iargc_ when specified as external - it provides entry points in the runtime for both iargc_ and for_iargc (disassembling the runtime shows that both have identical code). The version 7.1 of the compiler had the VAX/U*ix intrinsics in a separate portability library. g77 recognized several options to disable special intrinsics. In the case of iargc, g77 -funix-intrinsics-disable does the job. g95 does not recognize this option, and having -std=f95 doing too many things behind my back is counterproductive. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20248
[Bug ada/20226] [4.0/4.1 Regression] Error in __gnat_install_SEH_handler breaks bootstrap
--- Additional Comments From charlet at gcc dot gnu dot org 2005-03-01 08:54 --- Investigating... -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |charlet at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20226
[Bug c++/20232] [4.0/4.1 Regression] ICE with covariancy
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-01 09:57 --- Subject: Bug 20232 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-01 09:57:45 Modified files: gcc/cp : ChangeLog class.c cp-tree.h method.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/inherit: covariant12.C Log message: cp: PR c++/20232 * class.c (update_vtable_entry_for_fn): Don't crash on invalid covariancy. * cp-tree.g (THUNK_TARGET): Expand comment. * method.c (use_thunk): Make sure we also use the target, if that is a thunk. testsuite: PR c++/20232 * g++.dg/inherit/covariant12.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4649&r2=1.4650 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gcc&r1=1.707&r2=1.708 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&r1=1.1106&r2=1.1107 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/method.c.diff?cvsroot=gcc&r1=1.322&r2=1.323 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5100&r2=1.5101 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/inherit/covariant12.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20232
[Bug c++/20232] [4.0/4.1 Regression] ICE with covariancy
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-01 10:01 --- Subject: Bug 20232 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-01 10:00:49 Modified files: gcc/cp : ChangeLog class.c cp-tree.h method.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/inherit: covariant12.C Log message: cp: PR c++/20232 * class.c (update_vtable_entry_for_fn): Don't crash on invalid covariancy. * cp-tree.g (THUNK_TARGET): Expand comment. * method.c (use_thunk): Make sure we also use the target, if that is a thunk. testsuite: PR c++/20232 * g++.dg/inherit/covariant12.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.1&r2=1.4648.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.707&r2=1.707.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1106&r2=1.1106.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/method.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.322&r2=1.322.4.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.11&r2=1.5084.2.12 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/inherit/covariant12.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20232
[Bug c++/20232] [4.0/4.1 Regression] ICE with covariancy
--- Additional Comments From nathan at gcc dot gnu dot org 2005-03-01 10:02 --- 2005-03-01 Nathan Sidwell <[EMAIL PROTECTED]> PR c++/20232 * g++.dg/inherit/covariant12.C: New. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20232
[Bug libstdc++/17005] wide character strings don't work on HP-UX 11i using gcc 3.4.1
--- Additional Comments From hundertmarck at boehme-weihs dot de 2005-03-01 10:42 --- Now I have similar problem on HP-UX 11.00 (32). gcc does not find any definition of std::wstring. std::string is not useable too, in cause of unsatisfied symbols. A similar configuration works on HP-UX 11.11 (64). Has anybody an idea howto solve the problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17005
[Bug libstdc++/17005] wide character strings don't work on HP-UX 11i using gcc 3.4.1
--- Additional Comments From pcarlini at suse dot de 2005-03-01 11:01 --- Unfortunately, bad news: if I remember correctly, Dave doesn't mean to fix the problem on anything older that 11.11... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17005
[Bug libstdc++/17005] wide character strings don't work on HP-UX 11i using gcc 3.4.1
--- Additional Comments From hundertmarck at boehme-weihs dot de 2005-03-01 11:11 --- Whats the plan? Is it possibile that the problem would be fixed next time? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17005
[Bug c++/20207] null constructor not needed in multiple inheritance
--- Additional Comments From Serge dot Iovleff at univ-lille1 dot fr 2005-03-01 11:16 --- (In reply to comment #3) > it is invalid to use A0 in the base constructor list of D, because A0 is not a > virtual base for D. .it doesn't matter that the inheritance A->A0 is declared > virtual, 2 trees which both inherit A0 must join at D to use it in base > constructor list) No, I think it is invalid to use A0 in the base constructor list of B and C, even if g++ allow it... And I think also A0 is a virtual base for D, as it would appear twice (D inherit from B and C) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20207
[Bug libgcj/20251] [4.0 regression] libgcj configured with --enable-gtk-cairo fails on installation
--- Additional Comments From doko at debian dot org 2005-03-01 11:33 --- libtool doesn't add the -L/build/buildd/gcc-snapshot-20050227/build/ia64-linux-gnu/libjava/.libs argument, as it does for -L/build/buildd/gcc-snapshot-20050227/build/ia64-linux-gnu/libstdc++-v3/src -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20251
[Bug c/20258] error generated for storage class specified for function parameter
--- Additional Comments From neil at daikokuya dot co dot uk 2005-03-01 12:39 --- Subject: Re: error generated for storage class specified for function parameter schlie at comcast dot net wrote:- > Yes I understand. However it seems somewhat ironic that "static const" > already does just that, as it specifies the storage class and access What if it were the pointer that was like this? You need a type qualifier, not a storage class. Neil. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20258
[Bug fortran/20257] Fortran runtime error: End of record occurs when writing large arrays
--- Additional Comments From coudert at clipper dot ens dot fr 2005-03-01 13:10 --- This has indeed nothing to do with the output being redirected to a file, or stdout, or even being connected (in Fortran way) to a file: $ cat pr20257.f90 integer, parameter :: NX = 32, NR = 16, NPHI=2 real :: input(0:NX-1, 0:NR-1, 0:NPHI-1) input(:,:,:) = 0 open (10, file='foo') write(10,*) input end $ gfortran pr20257.f90 && ./a.out At line 6 of file pr20257.f90 Fortran runtime error: End of record -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20257
[Bug fortran/20257] Fortran runtime error: End of record occurs when writing large arrays
-- What|Removed |Added CC||coudert at clipper dot ens ||dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20257
[Bug libfortran/20257] Fortran runtime error: End of record occurs when writing large arrays
-- What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |NEW Component|fortran |libfortran Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-01 13:59:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20257
[Bug c/20260] gcc-3.4.3 crashes with a segmentation fault when compiling gtk+-2.6.3 on Linux.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01 14:03 --- Hmm, this works for me with 3.4.0 and on the mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20260
[Bug fortran/18518] equivalenced variables are not saved
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Last reconfirmed|2004-11-30 15:17:53 |2005-03-01 14:11:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18518
[Bug c++/20261] New: Error with integral-constant expression in template
Given this code:
template struct int_ {
static const T value = N;
typedef int_< T, static_cast(value+1) > next;
};
GCC says:
intconst2.cc:3: error: template argument 2 is invalid
It works if you replace "value" with "N".
Possibly related to recent changes to C++ parser disallow floating-point
literals in integral-constant expressions? Appeared around the same time.
This causes compilation failures in Boost.MPL
--
Summary: Error with integral-constant expression in template
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: redi at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20261
[Bug c++/20261] Error with integral-constant expression in template
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01 14:32 --- This has already fixed in a later version of gcc, at least 20050225. This is a dup of bug 20220. *** This bug has been marked as a duplicate of 20220 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20261
[Bug c++/20220] [4.0/4.1 Regression] Rejecting invalid template code, breaks most of Boost
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01 14:32 --- *** Bug 20261 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||redi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20220
[Bug target/19065] Make CRIS libstdc++ asms autoincrement-safe
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-01
14:57 ---
Subject: Bug 19065
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-03-01 14:57:25
Modified files:
gcc: ChangeLog
gcc/config/cris: cris.h cris.md
Log message:
PR target/19065.
* config/cris/cris.h (EXTRA_CONSTRAINT_Q): Accept only (mem (reg)),
not including (reg). Do not check for reg being CRIS_PC_REGNUM.
(EXTRA_MEMORY_CONSTRAINT): Define as 'Q'.
* config/cris/cris.md: Tweak comments referring to Q.
("cmpsi", "cmphi", "cmpqi", "*movsi_internal", "movhi")
("movstricthi", "movqi", "movstrictqi", "movsf", "addsi3")
("addhi3", "addqi3", "subsi3", "subhi3", "subqi3")
("*expanded_andsi", "*expanded_andhi", "*andhi_lowpart", "andqi3")
("*andqi_lowpart", "iorsi3", "iorhi3", "iorqi3", "uminsi3"):
Insert spaces in constraints to align alternatives vertically for
readability.
("cmphi"): Ditto. Add separate alternative for operand 0 "r",
operand 1: "M".
Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.13&r2=2.7592.2.14
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/cris/cris.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.84&r2=1.84.6.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/cris/cris.md.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.22&r2=1.22.2.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19065
[Bug libstdc++/17005] wide character strings don't work on HP-UX 11i using gcc 3.4.1
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-03-01 15:06 --- Subject: Re: wide character strings don't work on HP-UX > --- Additional Comments From pcarlini at suse dot de 2005-03-01 11:01 > --- > Unfortunately, bad news: if I remember correctly, Dave doesn't mean to fix > the > problem on anything older that 11.11... Yes, I believe that this is correct. The HP libc doesn't provide the support needed prior to 11.11. There is a HP web page that shows the timeline for the addition of various C95 (NA 2) and C99 features. Even with 11.11, the initial bootstrap requires special defines to allow configure to detect the wide character support (there is an issue with the declaration of iconv). I use for 4.x 32-bit builds with gcc versions prior to 4.0.0: export CC="gcc -D_XOPEN_UNIX -D_XOPEN_SOURCE_EXTENDED -D_INCLUDE__STDC_A1_SOURCE -D_INCLUDE_XOPEN_SOURCE_500" Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17005
[Bug middle-end/17278] [4.0/4.1 Regression] 8% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level
--- Additional Comments From kazu at cs dot umass dot edu 2005-03-01 15:08 --- Karel, could you retest the testcase with the gcc-4.0 branch? Several speed-up patches went in after your last benchmark. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17278
[Bug target/19065] Make CRIS libstdc++ asms autoincrement-safe
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-01 15:11 --- Subject: Bug 19065 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-01 15:10:41 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/config/cpu/cris: atomicity.h Log message: PR target/19065 * config/cpu/cris/atomicity.h (__exchange_and_add): In asm, use 'Q' constraint, not 'm'. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.2917.2.1&r2=1.2917.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/config/cpu/cris/atomicity.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.6&r2=1.6.46.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19065
[Bug tree-optimization/20216] [4.0 Regression] Simple loop runs out of stack at -O1
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01 15:12 --- Fixed at least on the mainline. -- What|Removed |Added Known to work||3.4.0 4.1.0 Summary|[4.0/4.1 Regression] Simple |[4.0 Regression] Simple loop |loop runs out of stack at - |runs out of stack at -O1 |O1 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20216
[Bug target/19065] Make CRIS libstdc++ asms autoincrement-safe
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-01 15:14 --- Subject: Bug 19065 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-01 15:14:25 Modified files: gcc: ChangeLog Log message: Correct cmphi comment in PR target/19065 change Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7623&r2=2.7624 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19065
[Bug c/20258] error generated for storage class specified for function parameter
--- Additional Comments From schlie at comcast dot net 2005-03-01 15:20 --- Subject: Re: error generated for storage class specified for function parameter > - Additional Comments From neil at daikokuya dot co dot uk 2005-03-01 >> Yes I understand. However it seems somewhat ironic that "static const" >> already does just that, as it specifies the storage class and access > > What if it were the pointer that was like this? You need a type > qualifier, not a storage class. - unless I misunderstand the question, the only way a pointer itself would be stored in ROM were if it were itself a static const value, and in turn would itself need to be referenced by a (static const *), where once referenced, (i.e. the pointer's value is now in a non-static variable) so it itself never be further qualified (I think)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20258
[Bug target/19065] Make CRIS libstdc++ asms autoincrement-safe
-- What|Removed |Added Target Milestone|4.1.0 |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19065
[Bug middle-end/19953] Special-case real + complex arithmetic operation (-ffast-math)
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-01
15:43 ---
(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #11)
> I get the same as I got above with the following version on x86:
> GNU C version 4.0.0 20050225 (experimental) (i686-pc-linux-gnu)
> compiled by GNU C version 4.0.0 20050225 (experimental).
> GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
> And no local patches which could cause this.
I can only assume that this has regressed, that this is a
little-endian problem (why it should be so is beyond me, though),
that your specific vibes make this go away or that mine make it
appear :-)
I have just done the following:
- Downloaded the 4.1 20050227 snapshot onto a ia-64 Linux box
- untarred it
$ mkdir gcc-bin
$ cd gcc-bin/
$ ../gcc-4.1-20050227/configure --prefix=$HOME --enable-languages="c,f95"
$ make -j2 bootstrap
$ make install
Then, I get:
$ gcc -v
Using built-in specs.
Target: ia64-unknown-linux-gnu
Configured with: ../gcc-4.1-20050227/configure --prefix=/home/zfkts
--enable-languages=c,f95
Thread model: posix
gcc version 4.1.0 20050227 (experimental)
$ cat c-div.c
#include
#include
int main()
{
float a;
complex float b,c;
foo(&a,&b);
c = b/a;
return creal(c) + cimag(c) < 0;
}
$ gcc -O3 -fdump-tree-optimized -S c-div.c
$ cat c-div.c.t65.optimized
;; Function main (main)
Analyzing Edge Insertions.
main ()
{
float SR.12;
float SR.11;
float SR.10;
float SR.9;
float c$imag;
float c$real;
float SR.6;
float SR.5;
float SR.4;
float SR.3;
float D.2255;
float D.2254;
float D.2253;
float D.2252;
float D.2251;
float D.2250;
float D.2249;
float D.2248;
float D.2247;
float D.2246;
float D.2245;
float D.2244;
float D.2243;
float D.2242;
float D.2241;
float D.2240;
float D.2239;
float D.2238;
float D.2237;
float D.2236;
float D.2233;
float D.2232;
float D.2231;
float D.2230;
float D.2229;
float D.2228;
complex float c;
complex float b;
float a;
double D.2225;
double D.2224;
float D.2223;
double D.;
float D.2221;
complex float c.2;
complex float c.1;
int D.2218;
complex float D.2217;
complex float D.2216;
float a.0;
:
foo (&a, &b);
SR.4 = a;
D.2228 = REALPART_EXPR ;
D.2229 = IMAGPART_EXPR ;
if (ABS_EXPR < 0.0) goto ; else goto ;
:;
D.2238 = SR.4 / 0.0;
D.2240 = SR.4 * D.2238 + 0.0;
c$real = (D.2229 + D.2228 * D.2238) / D.2240;
c$imag = (D.2229 * D.2238 - D.2228) / D.2240;
goto ;
:;
D.2247 = 0.0 / SR.4;
D.2249 = SR.4 + D.2247 * 0.0;
c$real = (D.2228 + D.2229 * D.2247) / D.2249;
c$imag = (D.2229 - D.2228 * D.2247) / D.2249;
:
return (double) c$real + (double) c$imag < 0.0;
}
Anything more I can do to test this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19953
[Bug preprocessor/20262] New: __LINE__ implementation flaky.
The following code snippet triggers the assert.
Interestingly, the exact message that you get depends on the gcc version. 2.9x
gives you a "6+1 != 6" message, where 3.x gives you a "7+1 != 7".
On gcc3.3.5:
silly: sillytest.c:7: main: Assertion `((7) + 1 == (7))' failed.
Aborted
The code is as follows.
#include
#define macro(a, b) ((a) + 1 == (b))
int
main(void)
{
assert(macro(__LINE__
, __LINE__));
return 0;
}
You're not alone - the only compiler I've found that does what I expect is the
SunWorkshop Pro compiler. Pretty much all the rest mess up somewhere along the
line!
Cheers,
David
--
Summary: __LINE__ implementation flaky.
Product: gcc
Version: 3.3.5
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david dot pye at osm dot co dot uk
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20262
[Bug target/20166] Bootstrap failure due to lack of fixinclude of pthread problem
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-03-01 16:01 --- We really need to fix this for 4.0.0 -- What|Removed |Added Severity|normal |critical Priority|P2 |P1 Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20166
[Bug middle-end/20218] Can't use __attribute__ ((visibility ("hidden"))) to hide a symbol
--- Additional Comments From hjl at lucon dot org 2005-03-01 16:04 --- The first attempt is at http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01835.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
[Bug c/20260] gcc-3.4.3 crashes with a segmentation fault when compiling gtk+-2.6.3 on Linux.
--- Additional Comments From tomdkat at comcast dot net 2005-03-01 16:07 --- I *was* able to compile gtk+-2.6.3 with gcc 3.4.4-20050225: [EMAIL PROTECTED]:~$ gcc -v Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/specs Configured with: ../configure --prefix=/usr --enable-languages=c,c++ --enable-shared Thread model: posix gcc version 3.4.4 20050225 (prerelease) [EMAIL PROTECTED]:~$ Peace... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20260
[Bug tree-optimization/20216] [4.0 Regression] Simple loop runs out of stack at -O1
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-01 16:22 --- Subject: Bug 20216 CVSROOT:/cvs/gcc Module name:gcc Branch: apple-ppc-branch Changes by: [EMAIL PROTECTED] 2005-03-01 16:21:44 Modified files: gcc: tree-chrec.c Added files: gcc/testsuite/gcc.dg: pr20216.c Log message: Radar 4022005 PR tree-optimization/20216 * tree-chrec.c (tree_fold_factorial): Delete. (tree_fold_binomial): Change argument list to take a return type and change the type of K to unsigned int. Rewrite to avoid explicit evaluation of factorials, and (recursively) calling fold to perform compile-time arithmetic. Return NULL on (internal) overflow. (chrec_evaluate): Change type of K to an unsigned int. Avoid calling tree_fold_binomial unnecessarily. Return chrec_dont_know if any intermediate calculation overflows. (chrec_apply): Update call to chrec_evaluate. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr20216.c.diff?cvsroot=gcc&only_with_tag=apple-ppc-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-chrec.c.diff?cvsroot=gcc&only_with_tag=apple-ppc-branch&r1=1.1.4.9&r2=1.1.4.10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20216
[Bug tree-optimization/20216] [4.0 Regression] Simple loop runs out of stack at -O1
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-01 16:28 --- Subject: Bug 20216 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-01 16:27:51 Modified files: gcc: ChangeLog tree-chrec.c Log message: PR tree-optimization/20216 * tree-chrec.c (tree_fold_factorial): Delete. (tree_fold_binomial): Change argument list to take a return type and change the type of K to unsigned int. Rewrite to avoid explicit evaluation of factorials, and (recursively) calling fold to perform compile-time arithmetic. Return NULL on (internal) overflow. (chrec_evaluate): Change type of K to an unsigned int. Avoid calling tree_fold_binomial unnecessarily. Return chrec_dont_know if any intermediate calculation overflows. (chrec_apply): Update call to chrec_evaluate. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.15&r2=2.7592.2.16 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-chrec.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.12&r2=2.12.12.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20216
[Bug target/20263] New: Incorrect asm for global register vars on sparc64
Using a global variable tied to register g7 generates invalid assembly
code on sparc64.
Consider:
register void *tp __asm__("%g7");
void set_tp() {
tp = 0;
}
Compiling this file produces an error and a warning from the assembler:
/usr/ccs/bin/as: "/var/tmp//ccLsIpQg.s", line 2: error: statement syntax
/usr/ccs/bin/as: "/var/tmp//ccLsIpQg.s", line 10: warning: detect global
register use not covered .register pseudo-op
Environment:
System: SunOS plg2.math 5.8 Generic_117350-18 sun4u sparc SUNW,Sun-Fire-880
Architecture: sun4
host: sparc64-sun-solaris2.8
build: sparc64-sun-solaris2.8
target: sparc64-sun-solaris2.8
configured with: ../gcc/configure --prefix=/u/rcbilson/software/gcc
--enable-languages=c,c++ sparc64-sun-solaris2.8
How-To-Repeat:
Attempt to compile the above program fragment.
--- Additional Comments From rcbilson at plg dot uwaterloo dot ca
2005-03-01 16:45 ---
Fix:
Examining the -S output shows that the .register op generated by the
compiler is
.register %g7, %g7
The second operand seems to be incorrect -- it ought to be a plain
name, not a register name. Replacing this op with
.register %g7, g7
allows the code to assemble, eliminating both the error and the
warning.
I don't know enough about .register to be confident in suggesting an
appropriate identifier to use for the second operand.
--
Summary: Incorrect asm for global register vars on sparc64
Product: gcc
Version: 1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rcbilson at plg dot uwaterloo dot ca
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: sparc64-sun-solaris2.8
GCC host triplet: sparc64-sun-solaris2.8
GCC target triplet: sparc64-sun-solaris2.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20263
[Bug target/20263] Incorrect asm for global register vars on sparc64
--- Additional Comments From rcbilson at plg dot uwaterloo dot ca 2005-03-01 16:50 --- I seem to have screwed something up in gccbug -- this is not a 2.95 issue. I've encoundered this problem with 3.4.3 and with the Feb. 28 mainline CVS version. -- What|Removed |Added Version|1.0 |2.95 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20263
[Bug target/20263] Incorrect asm for global register vars on sparc64
--- Additional Comments From rcbilson at plg dot uwaterloo dot ca 2005-03-01 16:52 --- Attempting to change "Reported against"... -- What|Removed |Added Version|2.95|4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20263
[Bug c/20258] error generated for storage class specified for function parameter
--- Additional Comments From joseph at codesourcery dot com 2005-03-01 16:56 --- Subject: Re: error generated for storage class specified for function parameter On Tue, 1 Mar 2005, schlie at comcast dot net wrote: > - unless I misunderstand the question, the only way a pointer itself would > be stored in ROM were if it were itself a static const value, and in turn > would itself need to be referenced by a (static const *), where once > referenced, (i.e. the pointer's value is now in a non-static variable) so > it itself never be further qualified (I think)? Just as you can have "char *" and "char *const" and "const char *" and "const char *const", you can have "ROM pointer to ROM" and "ROM pointer to RAM" and "RAM pointer to ROM" and "RAM pointer to RAM", and similarly with more levels of indirection. If you want to handle address spaces properly, look at DTR 18037 (or the final TR once the subclause numbering has been agreed with ISO). There is no bug here, although making GCC handle multiple address spaces properly in the manner described in DTR 18037 might be useful for some targets. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20258
[Bug target/20166] Bootstrap failure due to lack of fixinclude of pthread problem
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01 17:05 --- Well considering this is glibc bug, yes this needs to be fixed but really glibc should have this code in the first place as it would break with -pedantic and they were using an undocumented extension. -- What|Removed |Added Severity|critical|normal Priority|P1 |P2 Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20166
[Bug tree-optimization/20216] [4.0 Regression] Simple loop runs out of stack at -O1
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01 17:06 --- And now fixed on the 4.0 branch also. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20216
[Bug other/20264] New: error with `gmake check`
I updated my cvs tree today, and when I tried to `gmake check` I was presented with the following: [EMAIL PROTECTED]:/usr/local/src/gcc-build # gmake -d check | more This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Reading makefiles... Reading makefile `Makefile'... Updating makefiles Considering target file `Makefile'. Considering target file `/usr/local/src/gcc/Makefile.in'. Finished prerequisites of target file `/usr/local/src/gcc/Makefile.in'. No need to remake target `/usr/local/src/gcc/Makefile.in'. Considering target file `config.status'. Considering target file `/usr/local/src/gcc/configure'. .. Must remake target `maybe-check-etc'. Successfully remade target file `maybe-check-etc'. Considering target file `maybe-check-fastjar'. File `maybe-check-fastjar' does not exist. Considering target file `check-fastjar'. File `check-fastjar' does not exist. Finished prerequisites of target file `check-fastjar'. Must remake target `check-fastjar'. Putting child 0x08072cc0 (check-fastjar) PID 78160 on the chain. Live child 0x08072cc0 (check-fastjar) PID 78160 Got a SIGCHLD; 1 unreaped children. Reaping losing child 0x08072cc0 PID 78160 Removing child 0x08072cc0 PID 78160 from chain. [EMAIL PROTECTED]:/usr/local/src/gcc-build # Here is g++ --version [EMAIL PROTECTED]:/usr/local/src/gcc-build # g++-cvs --version g++-cvs (GCC) 4.1.0 20050301 (experimental) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [EMAIL PROTECTED]:/usr/local/src/gcc-build # And version info for configure. [EMAIL PROTECTED]:/usr/local/src/gcc # cvs status configure === File: configure Status: Up-to-date Working revision:1.206 Tue Mar 1 14:56:21 2005 Repository revision: 1.206 /usr/local/src/gcc-cvs/gcc/configure,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) [EMAIL PROTECTED]:/usr/local/src/gcc # [EMAIL PROTECTED]:~/projects/libglow $ uname -a FreeBSD lain.zehly.org 5.3-RELEASE-p5 FreeBSD 5.3-RELEASE-p5 #1: Sun Jan 30 12:36:24 EST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LAIN i386 Lemme know if you need more info. -- Summary: error with `gmake check` Product: gcc Version: tree-ssa Status: UNCONFIRMED Severity: critical Priority: P2 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jcobyrne at cox dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20264
[Bug other/20264] error with `gmake check`
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01 17:10 --- Use "gmake -k check" as described in the docs. -- What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |RESOLVED Resolution||INVALID Version|tree-ssa|4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20264
[Bug middle-end/19953] Special-case real + complex arithmetic operation (-ffast-math)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01 17:13 --- (In reply to comment #15) > I can only assume that this has regressed, that this is a > little-endian problem (why it should be so is beyond me, though), > that your specific vibes make this go away or that mine make it > appear :-) No because I tested on ppc-darwin also and got the same thing, -O3 -std=c99 enables flag_complex_method=2 IIRC. Also -ffast-math produces slightly different result but if you look at the final asm output you will see that the branch was removed, as I said before the branch is false always but that is a different bug which is already filed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19953
[Bug preprocessor/20262] __LINE__ implementation flaky.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01 17:16 --- Outer Macros are expanded before inner ones and they get all placed on one line so this is invalid. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20262
[Bug other/20264] error with `gmake check`
--- Additional Comments From jcobyrne at cox dot net 2005-03-01 17:16
---
Ok gmake[1]: Entering directory `/usr/local/src/gcc-build/fixincludes' autogen
-T /usr/local/src/gcc/fixincludes/check.tpl
/usr/local/src/gcc/fixincludes/inclhack.def gmake[1]: Leaving directory
`/usr/local/src/gcc-build/fixincludes' gmake[1]: Entering directory
`/usr/local/src/gcc-build/gcc' (rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd /usr/local/src/gcc/gcc; ${PWDCMD-pwd}` ; export srcdir ; \ cd
testsuite; \ EXPECT=expect ; export EXPECT ; \ if [ -f
${rootme}/../expect/expect ] ; then \TCL_LIBRARY=`cd .. ; cd
/usr/local/src/gcc/gcc/../tcl/library ; ${PWDCMD-pwd}` ; \ export
TCL_LIBRARY ; fi ; \ runtest --tool gcc ) (rootme=`${PWDCMD-pwd}`; export
rootme; \ srcdir=`cd /usr/local/src/gcc/gcc; ${PWDCMD-pwd}` ; export srcdir ; \
cd testsuite; \ EXPECT=expect ; export EXPECT ; \ if [ -f
${rootme}/../expect/expect ] ; then \TCL_LIBRARY=`cd .. ; cd
/usr/local/src/gcc/gcc/../tcl/library ; ${PWDCMD-pwd}` ; \ export
TCL_LIBRARY ; fi ; \ runtest --tool g++ ) (rootme=`${PWDCMD-pwd}`; export
rootme; \ srcdir=`cd /usr/local/src/gcc/gcc; ${PWDCMD-pwd}` ; export srcdir ; \
cd testsuite; \ EXPECT=expect ; export EXPECT ; \ if [ -f
${rootme}/../expect/expect ] ; then \TCL_LIBRARY=`cd .. ; cd
/usr/local/src/gcc/gcc/../tcl/library ; ${PWDCMD-pwd}` ; \ export
TCL_LIBRARY ; fi ; \ runtest --tool objc ) gmake[1]: Leaving directory
`/usr/local/src/gcc-build/gcc' gmake[1]: Entering directory
`/usr/local/src/gcc-build/intl' gmake[1]: Nothing to be done for `check'.
gmake[1]: Leaving directory `/usr/local/src/gcc-build/intl' gmake[1]: Entering
directory `/usr/local/src/gcc-build/libcpp' gmake[1]: Nothing to be done for
`check'. gmake[1]: Leaving directory `/usr/local/src/gcc-build/libcpp'
gmake[1]: Entering directory `/usr/local/src/gcc-build/libiberty' gmake[2]:
Entering directory `/usr/local/src/gcc-build/libiberty/testsuite'
./test-demangle < /usr/local/src/gcc/libiberty/testsuite/demangle-expected
./test-demangle: 746 tests, 0 failures gmake[2]: Leaving directory
`/usr/local/src/gcc-build/libiberty/testsuite' gmake[1]: Leaving directory
`/usr/local/src/gcc-build/libiberty' gmake[1]: Entering directory
`/usr/local/src/gcc-build/i386-cvsbuild-freebsd5/libstdc++-v3' Making check in
include gmake[2]: Entering directory
`/usr/local/src/gcc-build/i386-cvsbuild-freebsd5/libstdc++-v3/include'
gmake[2]: Nothing to be done for `check'. gmake[2]: Leaving directory
`/usr/local/src/gcc-build/i386-cvsbuild-freebsd5/libstdc++-v3/include' Making
check in libsupc++ gmake[2]: Entering directory
`/usr/local/src/gcc-build/i386-cvsbuild-freebsd5/libstdc++-v3/libsupc++'
gmake[2]: Nothing to be done for `check'. gmake[2]: Leaving directory
`/usr/local/src/gcc-build/i386-cvsbuild-freebsd5/libstdc++-v3/libsupc++' Making
check in libmath gmake[2]: Entering directory
`/usr/local/src/gcc-build/i386-cvsbuild-freebsd5/libstdc++-v3/libmath'
gmake[2]: Nothing to be done for `check'. gmake[2]: Leaving directory
`/usr/local/src/gcc-build/i386-cvsbuild-freebsd5/libstdc++-v3/libmath' Making
check in src gmake[2]: Entering directory
`/usr/local/src/gcc-build/i386-cvsbuild-freebsd5/libstdc++-v3/src' gmake[2]:
Nothing to be done for `check'. gmake[2]: Leaving directory
`/usr/local/src/gcc-build/i386-cvsbuild-freebsd5/libstdc++-v3/src' Making check
in po gmake[2]: Entering directory
`/usr/local/src/gcc-build/i386-cvsbuild-freebsd5/libstdc++-v3/po' gmake[2]:
Nothing to be done for `check'. gmake[2]: Leaving directory
`/usr/local/src/gcc-build/i386-cvsbuild-freebsd5/libstdc++-v3/po' Making check
in testsuite gmake[2]: Entering directory
`/usr/local/src/gcc-build/i386-cvsbuild-freebsd5/libstdc++-v3/testsuite' touch
testsuite_wchar_t touch testsuite_thread gmake -j1 check-DEJAGNU check-local
gmake[3]: Entering directory
`/usr/local/src/gcc-build/i386-cvsbuild-freebsd5/libstdc++-v3/testsuite'
srcdir=`CDPATH="${ZSH_VERSION+.}:" && cd
/usr/local/src/gcc/libstdc++-v3/testsuite && pwd`; export srcdir; \
EXPECT=expect; export EXPECT; \ runtest=runtest; \ if /bin/sh -c "$runtest
--version" > /dev/null 2>&1; then \ l='libstdc++'; for tool in $l; do \
$runtest --tool $tool --srcdir $srcdir ; \ done; \ else echo "WARNING: could
not find \`runtest'" 1>&2; :;\ fi gmake[3]: Nothing to be done for
`check-local'. gmake[3]: Leaving directory
`/usr/local/src/gcc-build/i386-cvsbuild-freebsd5/libstdc++-v3/testsuite'
gmake[2]: Leaving directory
`/usr/local/src/gcc-build/i386-cvsbuild-freebsd5/libstdc++-v3/testsuite'
gmake[2]: Entering directory
`/usr/local/src/gcc-build/i386-cvsbuild-freebsd5/libstdc++-v3' gmake
"AR_FLAGS=rc" "CC_FOR_BUILD=gcc"
"CC_FOR_TARGET=/usr/local/src/gcc-build/./gcc/xgcc
-B/usr/local/src/gcc-build/./gcc/ -$ gmake[3]: Entering directory
`/usr/local/src/gcc-build/i386-cvsbuild-freebsd5/libstdc++-v3' if [ -z "" ];
then \ true; \ else \ rootpre=`${PWDCMD-pwd}`/; expo
[Bug c/20260] gcc-3.4.3 crashes with a segmentation fault when compiling gtk+-2.6.3 on Linux.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01 17:17 --- Ok, I am going to close this as works for me then. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20260
[Bug other/20264] error with `gmake check`
--- Additional Comments From jcobyrne at cox dot net 2005-03-01 17:19
---
Ok that didn't work so well.
Let's try again.
gmake[1]: Entering directory `/usr/local/src/gcc-build/fixincludes'
autogen -
T /usr/local/src/gcc/fixincludes/check.tpl /usr/local/src/gcc/fixincludes/inclha
ck.def
gmake[1]: Leaving directory `/usr/local/src/gcc-build/fixincludes'
gmake[1]: Entering directory `/usr/local/src/gcc-build/gcc'
(rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd /usr/local/src/gcc/gcc; ${PWDCMD-pwd}` ; export srcdir ; \
cd testsuite; \
EXPECT=expect ; export EXPECT ; \
if [ -f ${rootme}/../expect/expect ] ; then \
TCL_LIBRARY=`cd .. ; cd /usr/local/src/gcc/gcc/../tcl/library ; ${PWDCMD-pwd}
` ; \
export TCL_LIBRARY ; fi ; \
runtest --tool gcc )
(rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd /usr/local/src/gcc/gcc; ${PWDCMD-pwd}` ; export srcdir ; \
cd testsuite; \
EXPECT=expect ; export EXPECT ; \
if [ -f ${rootme}/../expect/expect ] ; then \
TCL_LIBRARY=`cd .. ; cd /usr/local/src/gcc/gcc/../tcl/library ; ${PWDCMD-pwd}
` ; \
export TCL_LIBRARY ; fi ; \
runtest --tool g++ )
(rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd /usr/local/src/gcc/gcc; ${PWDCMD-pwd}` ; export srcdir ; \
cd testsuite; \
EXPECT=expect ; export EXPECT ; \
if [ -f ${rootme}/../expect/expect ] ; then \
TCL_LIBRARY=`cd .. ; cd /usr/local/src/gcc/gcc/../tcl/library ; ${PWDCMD-pwd}
` ; \
export TCL_LIBRARY ; fi ; \
runtest --tool objc )
gmake[1]: Leaving directory `/usr/local/src/gcc-build/gcc'
gmake[1]: Entering directory `/usr/local/src/gcc-build/intl'
gmake[1]: Nothing to be done for `check'.
gmake[1]: Leaving directory `/usr/local/src/gcc-build/intl'
gmake[1]: Entering directory `/usr/local/src/gcc-build/libcpp'
gmake[1]: Nothing to be done for `check'.
gmake[1]: Leaving directory `/usr/local/src/gcc-build/libcpp'
gmake[1]: Entering directory `/usr/local/src/gcc-build/libiberty'
gmake[2]: Entering directory `/usr/local/src/gcc-build/libiberty/testsuite'
./test-demangle < /usr/local/src/gcc/libiberty/testsuite/demangle-expected
./test-demangle: 746 tests, 0 failures
gmake[2]: Leaving directory `/usr/local/src/gcc-build/libiberty/testsuite'
gmake[1]: Leaving directory `/usr/local/src/gcc-build/libiberty'
gmake[1]: Entering directory `/usr/local/src/gcc-build/i386-cvsbuild-
freebsd5/libstdc++-v3'
Making check in include
gmake[2]: Entering directory `/usr/local/src/gcc-build/i386-cvsbuild-
freebsd5/libstdc++-v3/include'
gmake[2]: Nothing to be done for `check'.
gmake[2]: Leaving directory `/usr/local/src/gcc-build/i386-cvsbuild-
freebsd5/libstdc++-v3/include'
Making check in libsupc++
gmake[2]: Entering directory `/usr/local/src/gcc-build/i386-cvsbuild-
freebsd5/libstdc++-v3/libsupc++'
gmake[2]: Nothing to be done for `check'.
gmake[2]: Leaving directory `/usr/local/src/gcc-build/i386-cvsbuild-
freebsd5/libstdc++-v3/libsupc++'
Making check in libmath
gmake[2]: Entering directory `/usr/local/src/gcc-build/i386-cvsbuild-
freebsd5/libstdc++-v3/libmath'
gmake[2]: Nothing to be done for `check'.
gmake[2]: Leaving directory `/usr/local/src/gcc-build/i386-cvsbuild-
freebsd5/libstdc++-v3/libmath'
Making check in src
gmake[2]: Entering directory `/usr/local/src/gcc-build/i386-cvsbuild-
freebsd5/libstdc++-v3/src'
gmake[2]: Nothing to be done for `check'.
gmake[2]: Leaving directory `/usr/local/src/gcc-build/i386-cvsbuild-
freebsd5/libstdc++-v3/src'
Making check in po
gmake[2]: Entering directory `/usr/local/src/gcc-build/i386-cvsbuild-
freebsd5/libstdc++-v3/po'
gmake[2]: Nothing to be done for `check'.
gmake[2]: Leaving directory `/usr/local/src/gcc-build/i386-cvsbuild-
freebsd5/libstdc++-v3/po'
Making check in testsuite
gmake[2]: Entering directory `/usr/local/src/gcc-build/i386-cvsbuild-
freebsd5/libstdc++-v3/testsuite'
touch testsuite_wchar_t
touch testsuite_thread
gmake -j1 check-DEJAGNU check-local
gmake[3]: Entering directory `/usr/local/src/gcc-build/i386-cvsbuild-
freebsd5/libstdc++-v3/testsuite'
srcdir=`CDPATH="${ZSH_VERSION+.}:" && cd /usr/local/src/gcc/libstdc++-
v3/testsuite && pwd`; export srcdir; \
EXPECT=expect; export EXPECT; \
runtest=runtest; \
if /bin/sh -c "$runtest --version" > /dev/null 2>&1; then \
l='libstdc++'; for tool in $l; do \
$runtest --tool $tool --srcdir $srcdir ; \
done; \
else echo "WARNING: could not find \`runtest'" 1>&2; :;\
fi
gmake[3]: Nothing to be done for `check-local'.
gmake[3]: Leaving directory `/usr/local/src/gcc-build/i386-cvsbuild-
freebsd5/libstdc++-v3/testsuite'
gmake[2]: Leaving directory `/usr/local/src/gcc-build/i386-cvsbuild-
freebsd5/libstdc++-v3/testsuite'
gmake[2]: Entering directory `/usr/local/src/gcc-build/i386-cvsbuild-
freebsd5/libstdc++-v3'
gmake "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CC_FOR_TARGET=/usr/local/src/gcc-
build/./gcc/xgcc -B/usr/local/src/gcc-build/./gcc/ -$
gmake[3]: Entering directory `/usr/local/src/gcc-build/i386-cvsbuild-
freebsd5/libstdc++-v3'
if [ -z "" ]; then \
true; \
else \
rootpre=`${PWDCMD-pwd}`/; export ro
[Bug other/20264] error with `gmake check`
--- Additional Comments From jcobyrne at cox dot net 2005-03-01 17:22 --- Created an attachment (id=8304) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8304&action=view) ok this should be easier :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20264
[Bug java/8608] segmentation fault on compiling bad program
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-01 17:25 --- Subject: Bug 8608 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-01 17:24:55 Modified files: gcc/java : check-init.c ChangeLog Log message: PR java/8608 * check-init.c (wfl): Remove static. (final_assign_error, check_init): Replace calls to parse_error_context by plain error. (check_init): Save, set, and restore input_location for each exp. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/check-init.c.diff?cvsroot=gcc&r1=1.63&r2=1.64 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&r1=1.1558&r2=1.1559 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8608
[Bug other/20264] error with `gmake check`
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01 17:26 --- Looks like you don't have dejagnu installed or not in your path. This works for me and many other people. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20264
[Bug libobjc/19024] name collisions libobjc/libmysqlclient
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01 17:46 --- Here is how I would fix this use objc_hash_* in libobjc and then declare in hash.h, a deperated inline functions which call the new functions. The other thing would be have a new file which has those inline functions actually there so we can be still binary compatible. So: in hash.h, hash_new becomes objc_hash_new and there would be an inline function called hash_new which just calls objc_hash_new. in hash_compat.c, we have hash_new which just calls objc_hash_new. What do you think? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19024
[Bug target/20263] Incorrect asm for global register vars on sparc64
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01 17:47 --- Confirmed, we just forgot to remove the % from NAME when outputing it. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC build triplet|sparc64-sun-solaris2.8 | GCC host triplet|sparc64-sun-solaris2.8 | GCC target triplet|sparc64-sun-solaris2.8 |sparc64-*-* Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2005-03-01 17:47:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20263
[Bug debug/20253] [3.4/4.0/4.1 regression]: Macro debug info broken due to lexer change
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-03-01 18:00 --- I'll fix this bug if someone can test the fix on a stabs machine for me. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-02-28 20:12:18 |2005-03-01 18:00:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20253
[Bug tree-optimization/19126] Missed IV optimization (redundant instruction in loop)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01 18:09 --- (In reply to comment #2) > I get different asm for AMD64 as well: Since AMD64 and x86 have lea, it is not as impressive on PPC or any other target that does have a+b*c instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19126
[Bug tree-optimization/20165] Pointer does not really escape with write
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01 18:11 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-01 18:11:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20165
[Bug debug/20253] [3.4/4.0/4.1 regression]: Macro debug info broken due to lexer change
--- Additional Comments From dpatel at apple dot com 2005-03-01 18:18 --- Subject: Re: [3.4/4.0/4.1 regression]: Macro debug info broken due to lexer change On Mar 1, 2005, at 10:00 AM, dberlin at gcc dot gnu dot org wrote: > I'll fix this bug if someone can test the fix on a stabs machine for > me. I can run gdb test suite on powerpc-darwin. Note: FSF gdb does not have darwin port so darwin gdb is not similar to the one used by other stabs platform. - Devang -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20253
[Bug libgcj/20265] New: Unable to generate a shared library from a jar file using gcj v4.0
I am using version 4.0 of gcj and when trying to convert a jar to a shared library I get the following: [EMAIL PROTECTED] WMQ]$ gcj -I /home/acuser/gcj/WMQ -shared com.ibm.mq.jar -o mq- shared.so com/ibm/mq/BindingsConnectionRequestInfo.java:0: error: cannot find file for class javax.resource.spi.ConnectionRequestInfo com/ibm/mq/BindingsConnectionRequestInfo.java:0: error: cannot find file for class javax.resource.spi.ConnectionRequestInfo com/ibm/mq/MQConnectionRequestInfo.java:0: error: cannot find file for class javax.resource.spi.ConnectionRequestInfo com/ibm/mq/MQConnectionRequestInfo.java:0: confused by earlier errors, bailing out The ConnectionRequestInfo.class file is in another jar in the same directory as the com.ibm.mq.jar file. Which is the same directory that I am running gcj out of. I got the same errors when I was using version 3.2 but I got around it by adding the -I parameter. But now using version 4.0 the errors are back. Am I missing a parameter? Help. -- Summary: Unable to generate a shared library from a jar file using gcj v4.0 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bparker at ilstechnology dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20265
[Bug libgcj/20265] Unable to generate a shared library from a jar file using gcj v4.0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01 18:27 --- try -I /home/acuser/gcj/WMQ/other.jar -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20265
[Bug tree-optimization/18727] [4.0/4.1 Regression] ACATS c43214c fails at runtime (aliasing pb)
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-01 18:33 --- It should be fixed by the next push from AdaCore. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18727
[Bug libgcj/20266] New: Using v4 of gcj I am unable to build an executable from shared libraries
Using gcj verion 4 running on red Hat Enterprise Linux ES release 3 I tried to
create a executable using shared libraries I had previously created. I got the
following results:
[EMAIL PROTECTED] WMQ]$ gcj --main=mqTester -o mqTester mqTester.java -L. -
lconnector-shared -lmq-shared
mqTester.java:18: error: Can't find default package ΓÇÿcom.ibm.mqΓÇÖ.
Check the
CLASSPATH environment variable and the access to the archives
mqTester.java:49: error: Type ΓÇÿMQQueueManagerΓÇÖ not found in the
declaration
of the local variable ΓÇÿqMgrΓÇÖ.
MQQueueManager qMgr = null;
^
mqTester.java:50: error: Type ΓÇÿMQQueueΓÇÖ not found in the
declaration of the
local variable ΓÇÿlocal_queueΓÇÖ.
MQQueue local_queue = null;
^
mqTester.java:144: error: Type ΓÇÿMQMessageΓÇÖ not found in the
declaration of
the local variable ΓÇÿhello_worldΓÇÖ.
MQMessage hello_world = new MQMessage();
^
mqTester.java:151: error: Type ΓÇÿMQPutMessageOptionsΓÇÖ not found in
the
declaration of the local variable ΓÇÿpmoΓÇÖ.
MQPutMessageOptions pmo = new MQPutMessageOptions();
^
mqTester.java:186: error: Type ΓÇÿMQExceptionΓÇÖ not found in the
declaration
of the local variable ΓÇÿmeΓÇÖ.
catch (MQException me) {
^
mqTester.java:197: error: Type ΓÇÿMQExceptionΓÇÖ not found in the
declaration
of the local variable ΓÇÿmqeΓÇÖ.
} catch (MQException mqe ) {
^
7 errors
The classes MQQueueManager, MQException, MQPutMessageOptions, etc. referenced
above all reside in the mq-shared shared library, which was built from a jar
file and resides in the /home/acuser/gcj/WMQ directory.
I am running this from the /home/acuser/gcj/WMQ directory. My classpath is set
to the folloing:
[EMAIL PROTECTED] WMQ]$ echo $CLASSPATH
/home/acuser/gcj/WMQ:.
My path is set to the following:
[EMAIL PROTECTED] WMQ]$ echo $PATH
/usr/local/bin:/bin:/usr/bin:/home/acuser/gcj/WMQ:/home/acuser/bin
FYI..the main program compiles and run successfully on the same box if I do the
folowing from the command line
[EMAIL PROTECTED] WMQ]$java -cp com.ibm.mq.jar:connector.jar: mqTester -QMgr
AIX.QUEUE.MANAGER -QName AIX.DATA.QUEUE -hostname 192.168.1.36 -channel
CHANNEL1 -port 1416
--
Summary: Using v4 of gcj I am unable to build an executable from
shared libraries
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bparker at ilstechnology dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20266
[Bug libgcj/20266] Using v4 of gcj I am unable to build an executable from shared libraries
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01 19:23 --- I think you are missing that gcj does not look into .jar files in the CLASSPATH, if you add the .jar file to the CLASSPATH it should work, can you try that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20266
[Bug target/20166] Bootstrap failure due to lack of fixinclude of pthread problem
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-03-01 19:33 --- Yes, glibc should have this code in the first place but we can not turn the clock back/time travel. Futhermore, I can reproduce it on i686-pc-linux-gnu with NPTL-enabled glibc-2.3.3 system using official tarball with no patches. IMHO, it's quite important for folks using NPTL-enabled systems to bootstrap GCC 4.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20166
[Bug target/20263] Incorrect asm for global register vars on sparc64
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-01 19:52 --- Fixing. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20263
[Bug libgcj/20267] New: too few arguments to function _Jv_AllocObject when class/object instantiated with new operator.
Here is the compilation failure I am facing out of libgcj build, I am only concerned with the "too few arguments to function error" prims.cc: In function `void unblock_signal(int)': prims.cc:136: warning: right-hand operand of comma has no effect prims.cc:137: warning: right-hand operand of comma has no effect java/lang/Class.h: In function `void _Jv_ThrowBadArrayIndex(jint)': java/lang/Class.h:289: error: too few arguments to function `java::lang::Object* _Jv_AllocObject(java::lang::Class*, jint)' prims.cc:343: error: at this point in file java/lang/Class.h: In function `void _Jv_ThrowNullPointerException()': java/lang/Class.h:289: error: too few arguments to function `java::lang::Object* _Jv_AllocObject(java::lang::Class*, jint)' prims.cc:349: error: at this point in file prims.cc: In function `JArray* _Jv_NewObjectArray(jsize, java::lang::Class*, java::lang::Object*)': prims.cc:421: error: too few arguments to function `java::lang::Object* _Jv_AllocObject(java::lang::Class*, jint)' prims.cc:480: error: at this point in file prims.cc: In function `java::lang::Object* _Jv_NewPrimArray (java::lang::Class*, jint)': prims.cc:421: error: too few arguments to function `java::lang::Object* _Jv_AllocObject(java::lang::Class*, jint)' prims.cc:519: error: at this point in file prims.cc: In function `java::lang::Object* _Jv_NewArray(jint, jint)': prims.cc:421: error: too few arguments to function `java::lang::Object* _Jv_AllocObject(java::lang::Class*, jint)' prims.cc:564: error: at this point in file prims.cc: In function `java::lang::Object* _Jv_NewMultiArray (java::lang::Class*, jint, jint*)': prims.cc:421: error: too few arguments to function `java::lang::Object* _Jv_AllocObject(java::lang::Class*, jint)' prims.cc:598: error: at this point in file prims.cc: In function `java::lang::Object* _Jv_NewMultiArray (java::lang::Class*, jint, ...)': prims.cc:421: error: too few arguments to function `java::lang::Object* _Jv_AllocObject(java::lang::Class*, jint)' prims.cc:613: error: at this point in file prims.cc: In function `JArray* JvConvertArgv(int, const char**)': prims.cc:421: error: too few arguments to function `java::lang::Object* _Jv_AllocObject(java::lang::Class*, jint)' prims.cc:721: error: at this point in file prims.cc: In function `jint _Jv_CreateJavaVM(void*)': prims.cc:421: error: too few arguments to function `java::lang::Object* _Jv_AllocObject(java::lang::Class*, jint)' prims.cc:946: error: at this point in file prims.cc:421: error: too few arguments to function `java::lang::Object* _Jv_AllocObject(java::lang::Class*, jint)' prims.cc:965: error: at this point in file prims.cc: In function `void _Jv_RunMain(java::lang::Class*, const char*, int, const char**, bool)': prims.cc:421: error: too few arguments to function `java::lang::Object* _Jv_AllocObject(java::lang::Class*, jint)' prims.cc:1003: error: at this point in file prims.cc:421: error: too few arguments to function `java::lang::Object* _Jv_AllocObject(java::lang::Class*, jint)' prims.cc:1006: error: at this point in file prims.cc: In function `jint _Jv_divI(jint, jint)': prims.cc:421: error: too few arguments to function `java::lang::Object* _Jv_AllocObject(java::lang::Class*, jint)' prims.cc:1114: error: at this point in file prims.cc: In function `jint _Jv_remI(jint, jint)': prims.cc:421: error: too few arguments to function `java::lang::Object* _Jv_AllocObject(java::lang::Class*, jint)' prims.cc:1130: error: at this point in file prims.cc: In function `jlong _Jv_divJ(jlong, jlong)': prims.cc:421: error: too few arguments to function `java::lang::Object* _Jv_AllocObject(java::lang::Class*, jint)' prims.cc:1146: error: at this point in file prims.cc: In function `jlong _Jv_remJ(jlong, jlong)': prims.cc:421: error: too few arguments to function `java::lang::Object* _Jv_AllocObject(java::lang::Class*, jint)' prims.cc:1162: error: at this point in file prims.cc: At global scope: prims.cc:132: warning: 'void unblock_signal(int)' defined but not used Here are the compilation options that happened to be issued: -D_GNU_SOURCE -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -W -Wall-fPIC -gdwarf-2 -fverbose-asm -fmessage-length=0 -O0 -funsigned-char -Wno-format-extra-args -fno-builtin-abort -fno-builtin-exit -DPIC Anyone seen this before? Seems to be related to the "new" operator on a object. If you look at the source of some of these functions that are complaining they don't even issue _Jv_AllocObject from the code's point of view. The only thing I could think of is that the compiler (c++?) is generating calls to _Jv_AllocObject and for some reason isn't creating the parameters correctly, or the check for the parameters is confused. Does this seem impossible? Or anyone could mention what segements in the compiler manage this. A scrap of direction here :). -- Summary: too few arguments to function _Jv_AllocObject when class/object instantiated with new
[Bug libgcj/20267] too few arguments to function _Jv_AllocObject when class/object instantiated with new operator.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01 20:17 --- You seem to intermixing compiler versions and libgcj versions. This works for me and many other people. How are you building gcj/libgcj? Are you really building the full GCC or just libjava (which is not supported at all)? -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20267
[Bug fortran/19576] character(*) initialization
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-01 20:17 --- Reduced testcase: program achar_test implicit none integer i character(*), parameter :: y(0:1) = (/'0','1'/) write(*,*) y end program achar_test This has nothing to do with ACHAR, and is the same issue as PR15959. *** This bug has been marked as a duplicate of 15959 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE Summary|achar in initialization |character(*) initialization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19576
[Bug fortran/15959] ICE and assertion failure in trans-decl.c with character initialization
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-01 20:17 --- *** Bug 19576 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||coudert at clipper dot ens ||dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15959
[Bug fortran/19693] optimization problem with LAPACK routine cgtts2.f
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-01 20:22 --- Can this be closed with the recent change of default complex divide algorithm? -- What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19693
[Bug fortran/15959] ICE and assertion failure in trans-decl.c with character initialization
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-01 20:31 --- Reduced testcase: character(*), parameter :: y(1:1) = (/'0'/) print *,y end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15959
[Bug middle-end/19953] Special-case real + complex arithmetic operation (-ffast-math)
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-01 21:07 --- Andrew, I'm sorry if I'm not making myself clear here. The problem that I see is that, on ia64-unknown-linux-gnu and on i386-pc-linux-gnu, with clean trees, I see code like :; D.2390 = 0.0 / SR.22; D.2392 = SR.22 + D.2390 * 0.0; c$real = (D.2371 + D.2372 * D.2390) / D.2392; c$imag = (D.2372 - D.2371 * D.2390) / D.2392; in *.t65.optimized for the simple test case with -O1 and -O3. As you have stated, this is independent of PR 20139. I just rechecked this with the 4.0.0 20050226 (prerelease) snapshot. You have posted different results, which I cannot reproduce. Something has to be the cause of this difference, but I have no real idea what it could be. Is the *.t65.optimized that I am looking at the correct file? Is there any patch in your tree that may be the cause of these of these different results after all? What version are you using, exactly? How can I download the exact version from cvs? Can this be caused by header files? I think that this is highly unlikely, this is why I didn't include the preprocessed source, but I can do so, of course. Is there anything else that I can do to clear this up? Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19953
[Bug debug/20268] New: g++ generates incomplete debug information for given testcase
It appears that g++ is generating incorrect scope debug information
for inlined functions. One symptom of this is that addr2line will
generate inconsistent results for the affected address ranges, showing
the correct line information for the inlined function, but showing the
function name as the most outer scope that contains the inlined
function.
For example, it may show a line number in a C++ header file and give
the function name as "main".
Environment:
System: Linux toadfish.ninemoons.com 2.6.9-1.681_FC3.stk16 #1 Mon Nov 22
16:44:32 EST 2004 i686 i686 i386 GNU/Linux
Architecture: i686
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: /src/sourceware/gcc/gcc/configure -v
--prefix=/opt/local/sourceware --enable-languages=c,c++
How-To-Repeat:
Compile and link this code:
#include
using namespace std;
int main ()
{
vector V(10);
V[10] = 1;
}
using a command like:
g++ -ggdb -O2 --save-temps -o t t.cc
Below is an annotated copy of the disassembly of main().
First I removed all the instruction pattern fields since they just
clutter stuff up for our purposes. Having the instruction name and
args is sufficient to see what the code is doing.
Next I ran addr2line on every address, collected the output function
name and line number info, and inserted that as columns 2 and 3 (after
the instruction address and before the instruction name).
Next I examined the dwarf output and looked for the most outer scopes
of the inlined functions. I.E. if DW_TAG_subprogram is scope '<1>'
then I looked for the inlined subroutines at scope '<2>' and inserted
lines in the disassembly at the beginning (beg) and ending (end) of
each scope. This shows the coverage of the function code for inlined
functions. Code outside these scopes SHOULD belong only to code in
main() itself.
If you look at the function names emitted by addr2line (the second
column) you will note that it associates any code outside the scope of
the beg...end regions as belonging to main. All of these SHOULD have
filenames from the line number info of "t.cc". However some of these
ranges identified as code belonging to main are actually code from
inlined functions in the C++ headers, thus there must be some missing
DW_TAG_inlined_subroutine DIES for these sections. For example:
0x804896b main mt_allocator.h:450 call 80486c4 <[EMAIL PROTECTED]>
where the code at line 450 in mt_allocator.h is:
static pool_type&
_S_get_pool()
{
450->static pool_type _S_pool;
return _S_pool;
}
08048880 :
beg <1><39c1>: Abbrev Number: 111 (DW_TAG_subprogram)
0x8048880 maint.cc:5 push %ebp
0x8048881 maint.cc:5 mov%esp,%ebp
0x8048883 maint.cc:5 push %ebx
0x8048884 maint.cc:5 sub$0x34,%esp
0x8048887 maint.cc:5 and$0xfff0,%esp
0x804888a maint.cc:5 sub$0x10,%esp
beg <2><39e7>: Abbrev Number: 92 (DW_TAG_inlined_subroutine): vector
0x804888d _S_get_pool mt_allocator.h:450 cmpb $0x0,0x804a768
0x8048894 _S_get_pool mt_allocator.h:450 je 8048964
0x804889a _M_allocate stl_vector.h:117xor%eax,%eax
0x804889c _M_allocate stl_vector.h:117lea
0xffe8(%ebp),%ebx
0x804889f _M_allocate stl_vector.h:117mov%eax,0x8(%esp)
0x80488a3 _M_allocate stl_vector.h:117mov$0xa,%eax
0x80488a8 _Vector_implstl_vector.h:85 movl
$0x0,0xffe8(%ebp)
0x80488af _Vector_implstl_vector.h:85 movl
$0x0,0xffec(%ebp)
0x80488b6 _Vector_implstl_vector.h:85 movl
$0x0,0xfff0(%ebp)
0x80488bd _Vector_basestl_vector.h:117mov%eax,0x4(%esp)
0x80488c1 _Vector_basestl_vector.h:117mov%ebx,(%esp)
0x80488c4 _Vector_basestl_vector.h:117call 8049140
<__gnu_cxx::__mt_alloc >::allocate(unsigned int, void const*)>
0x80488c9 _S_get_pool mt_allocator.h:450 cmpb $0x0,0x804a768
0x80488d0 vector stl_vector.h:103mov
%eax,0xffe8(%ebp)
0x80488d3 vector stl_vector.h:104mov
%eax,0xffec(%ebp)
0x80488d6 vector stl_vector.h:105lea0x28(%eax),%eax
0x80488d9 vector stl_vector.h:105mov
%eax,0xfff0(%ebp)
0x80488dc vector mt_allocator.h:450 je 8048a50
0x80488e2 vector stl_vector.h:219lea
0xfffa(%ebp),%eax
0x80488e5 vector stl_vector.h:219mov$0xa,%edx
0x80488ea vector stl_vector.h:219mov%eax,0
[Bug middle-end/19953] Special-case real + complex arithmetic operation (-ffast-math)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01 21:14 --- (In reply to comment #17) > Andrew, > > I'm sorry if I'm not making myself clear here. > > The problem that I see is that, on ia64-unknown-linux-gnu and on > i386-pc-linux-gnu, with clean trees, I see code like > > :; > D.2390 = 0.0 / SR.22; > D.2392 = SR.22 + D.2390 * 0.0; > c$real = (D.2371 + D.2372 * D.2390) / D.2392; > c$imag = (D.2372 - D.2371 * D.2390) / D.2392; > > in *.t65.optimized for the simple test case with -O1 and -O3. As you > have stated, this is independent of PR 20139. Yes that code is correct. as 0.0/SR.22 is not 0.0 if SR.22 is NAN. and 0.0 * D.2390 is not 0.0 if D.2390 is NAN. Try -ffast-math or -fno-trapping-math or -ffinite-math-only. > I just rechecked this with the 4.0.0 20050226 (prerelease) snapshot. > You have posted different results, which I cannot reproduce. Yes I posted results with -ffast-math and other options as you described in comment #8: > $ gcc -ffast-math -O3 -fdump-tree-optimized -fno-cx-limited-range -S c-div.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19953
[Bug debug/20268] g++ generates incomplete debug information for given testcase with optimization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01 21:16 --- What version of gcc can you reproduce this with? Give the output of "gcc -v"? -- What|Removed |Added Summary|g++ generates incomplete|g++ generates incomplete |debug information for given |debug information for given |testcase|testcase with optimization Version|1.0 |unknown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20268
[Bug debug/20268] g++ generates incomplete debug information for given testcase with optimization
--- Additional Comments From fnf at diveadx dot com 2005-03-01 21:21 --- Subject: Re: g++ generates incomplete debug information for given testcase with optimization On Tuesday 01 March 2005 15:16, pinskia at gcc dot gnu dot org wrote: > What version of gcc can you reproduce this with? > Give the output of "gcc -v"? $ g++ -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /src/sourceware/gcc/gcc/configure -v --prefix=/opt/local/sourceware --enable-languages=c,c++ Thread model: posix gcc version 4.1.0 20050301 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20268
[Bug middle-end/19953] Special-case real + complex arithmetic operation (-ffast-math)
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-01 21:26 --- (In reply to comment #18) > > :; > > D.2390 = 0.0 / SR.22; > > D.2392 = SR.22 + D.2390 * 0.0; > > c$real = (D.2371 + D.2372 * D.2390) / D.2392; > > c$imag = (D.2372 - D.2371 * D.2390) / D.2392; > > > > in *.t65.optimized for the simple test case with -O1 and -O3. As you > > have stated, this is independent of PR 20139. > > Yes that code is correct. as 0.0/SR.22 is not 0.0 if SR.22 is NAN. > and 0.0 * D.2390 is not 0.0 if D.2390 is NAN. Ok, then I have misunderstood you - you were referring to the results with -ffast-math. However, there still is a missed optimization here. If SR.22 is NaN, then the proposed simplification c$real = D.2371 / SR.22; c$imag = D.2372 / SR.22 would still yield NaN for c$real and c$imag, which is correct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19953
[Bug c/20258] error generated for storage class specified for function parameter
--- Additional Comments From schlie at comcast dot net 2005-03-01 21:41 --- Subject: Re: error generated for storage class specified for function parameter > --- Additional Comments From joseph at codesourcery dot com 2005-03-01 > Subject: error generated for storage class specified for function parameter > >> On Tue, 1 Mar 2005, schlie at comcast dot net wrote: >> - unless I misunderstand the question, the only way a pointer itself would >> be stored in ROM were if it were itself a static const value, and in turn >> would itself need to be referenced by a (static const *), where once >> referenced, (i.e. the pointer's value is now in a non-static variable) so >> it itself never be further qualified (I think)? > > Just as you can have "char *" and "char *const" and "const char *" and > "const char *const", you can have "ROM pointer to ROM" and "ROM pointer to > RAM" and "RAM pointer to ROM" and "RAM pointer to RAM", and similarly with > more levels of indirection. > > If you want to handle address spaces properly, look at DTR 18037 (or the > final TR once the subclause numbering has been agreed with ISO). There is > no bug here, although making GCC handle multiple address spaces properly > in the manner described in DTR 18037 might be useful for some targets. Thank you for the reference, and do also agree there's no "bug" in the present implementation. However do observe that although the present use of of a storage-class specifier in the context of a parameter type-qualifier is not supported by the present standard; it may be worthy of consideration as a sensible optionally enabled extension; as the use of the combination "static const" in this context seems fully consistent with the specification of an otherwise explicit ROM address-space-qualifier, as it is just this combination which is typically used to identify values which may be stored as ROM'ed data. Therefore seems reasonable to consider compatibly optionally extending the use of "static const" as an implied read-only address-space qualifier, as it would not introduce any ambiguities because it's present use in this context is not supported (and seems easier to initially enable, than DTR18037 is). Might you be willing to consider a patch enabling this option use? --- As an aside, with respect to the various permutations of static const *, etc. It seems that by simply designating the combination "static const" as an optional legal type qualifier within contexts not otherwise supporting the designation of a storage-class specifier, GCC can be relatively easily enabled to support an implied primitive ROM address-space which is distinct from the remaining default address space (being implied by everything not "static const"). For example, with respect to the optional extension of "static const" as a function parameter's qualifier, since parameters are passed in RAM, ROM (i.e. "static const") values may only be passed by reference by definition, which eliminates I believe much of it's potential complexity. For example: int foo (int * static const x); Is physically impossible, as parameters are implied to be variable, therefore must be passed in RAM, therefore must not in ROM. However as you note, with the exception of this restriction, any subsequent hierarchy of qualifiers would be valid, although some of likely limited practical use. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20258
[Bug debug/20268] g++ generates incomplete debug information for given testcase with optimization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01 21:47 --- Is there a way to produce the output you gave easily? Also why do you think gcc should produce good debug information with optimizations since scheduling can change ording of instructions so it causes DW_TAG_inlined_subroutine to be wrong. -- What|Removed |Added Version|unknown |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20268
[Bug libgcj/20160] [4.0/4.1 Regression] link errors building libgcj tests
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-01
22:27 ---
Subject: [PR libgcj/20160] rename archive members with duplicate basenames
The archives created for libjava are broken, in that some of the
object files that should go into it are missing. That's because AR
is supposed to drop dirname components of pathnames in archive
members. Libtool was already careful enough to ensure the all archive
members made to the convenience library, by using ar cq if creating
archives piecewise, but it isn't as careful when extracting the
archive members to create other archives with them, so we end up
dropping all but the last-added overlapping-basename object from the
second-generation archive.
This problem is already fixed in libtool mainline and 1.5 branches,
using some clever tricks at extract time, that I'm not entirely
comfortable with, and not quite willing to back-port. Until we
actually upgrade to a newer libtool, I'd rather go with this change
that is IMHO safer, but unfortunately introduces some additional
overhead in archive creation time. Oh well...
I'm checking this in mainline and 4.0 branch. Tested on
arm-elf (thanks Richard!) and x86_64-linux-gnu.
Index: ChangeLog
from Alexandre Oliva <[EMAIL PROTECTED]>
PR libgcj/20160
* ltmain.sh: Avoid creating archives with components that have
duplicate basenames.
* libjava/configure: Rebuilt.
Index: ltmain.sh
===
RCS file: /cvs/gcc/gcc/ltmain.sh,v
retrieving revision 1.24
diff -u -p -r1.24 ltmain.sh
--- ltmain.sh 8 Sep 2004 15:43:46 - 1.24
+++ ltmain.sh 1 Mar 2005 22:16:48 -
@@ -4307,6 +4307,63 @@ fi\
#fi
# done
+ # POSIX demands no paths to be encoded in archives. We have
+ # to avoid creating archives with duplicate basenames if we
+ # might have to extract them afterwards, e.g., when creating a
+ # static archive out of a convenience library, or when linking
+ # the entirety of a libtool archive into another (currently
+ # not supported by libtool).
+if (for obj in $oldobjs
+ do
+ $echo "X$obj" | $Xsed -e 's%^.*/%%'
+ done | sort | sort -uc >/dev/null 2>&1); then
+ :
+ else
+ $echo "copying selected object files to avoid basename conflicts..."
+
+ if test -z "$gentop"; then
+ gentop="$output_objdir/${outputname}x"
+
+ $show "${rm}r $gentop"
+ $run ${rm}r "$gentop"
+ $show "$mkdir $gentop"
+ $run $mkdir "$gentop"
+ status=$?
+ if test $status -ne 0 && test ! -d "$gentop"; then
+ exit $status
+ fi
+ generated="$generated $gentop"
+ fi
+
+ save_oldobjs=$oldobjs
+ oldobjs=
+ counter=1
+ for obj in $save_oldobjs
+ do
+ objbase=`$echo "X$obj" | $Xsed -e 's%^.*/%%'`
+ case " $oldobjs " in
+ " ") oldobjs=$obj ;;
+ *[\ /]"$objbase "*)
+ while :; do
+ # Make sure we don't pick an alternate name that also
+ # overlaps.
+ newobj=lt$counter-$objbase
+ counter=`expr $counter + 1`
+ case " $oldobjs " in
+ *[\ /]"$newobj "*) ;;
+ *) if test ! -f "$gentop/$newobj"; then break; fi ;;
+ esac
+ done
+ $show "ln $obj $gentop/$newobj || cp $obj $gentop/$newobj"
+ $run ln "$obj" "$gentop/$newobj" ||
+ $run cp "$obj" "$gentop/$newobj"
+ oldobjs="$oldobjs $gentop/$newobj"
+ ;;
+ *) oldobjs="$oldobjs $obj" ;;
+ esac
+ done
+ fi
+
eval cmds=\"$old_archive_cmds\"
if len=`expr "X$cmds" : ".*"` &&
@@ -4320,20 +4377,7 @@ fi\
objlist=
concat_cmds=
save_oldobjs=$oldobjs
- # GNU ar 2.10+ was changed to match POSIX; thus no paths are
- # encoded into archives. This makes 'ar r' malfunction in
- # this piecewise linking case whenever conflicting object
- # names appear in distinct ar calls; check, warn and compensate.
- if (for obj in $save_oldobjs
- do
- $echo "X$obj" | $Xsed -e 's%^.*/%%'
- done | sort | sort -uc >/dev/null 2>&1); then
- :
- else
- $echo "$modename: warning: object name conflicts; overriding
AR_FLAGS to 'cq'" 1>&2
- $echo "$modename: warning: to ensure that POSIX-compatible ar will
work" 1>&2
- AR_FLAGS=cq
- fi
+
for obj in $save_oldobjs
do
oldobjs="$objlist $obj"
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
--
http://gcc.gnu.org/bugzilla/show_
[Bug libgcj/20160] [4.0/4.1 Regression] link errors building libgcj tests
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-01 22:27 --- Subject: Bug 20160 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-01 22:27:44 Modified files: . : ChangeLog ltmain.sh Log message: PR libgcj/20160 * ltmain.sh: Avoid creating archives with components that have duplicate basenames. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/ChangeLog.diff?cvsroot=gcc&r1=1.1061&r2=1.1062 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/ltmain.sh.diff?cvsroot=gcc&r1=1.24&r2=1.25 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20160
[Bug libgcj/20160] [4.0/4.1 Regression] link errors building libgcj tests
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-01 22:29 --- Subject: Bug 20160 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-01 22:29:34 Modified files: . : ChangeLog ltmain.sh Log message: PR libgcj/20160 * ltmain.sh: Avoid creating archives with components that have duplicate basenames. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1057&r2=1.1057.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/ltmain.sh.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.24&r2=1.24.30.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20160
[Bug c/20258] error generated for storage class specified for function parameter
--- Additional Comments From joseph at codesourcery dot com 2005-03-01 22:30 --- Subject: Re: error generated for storage class specified for function parameter On Tue, 1 Mar 2005, schlie at comcast dot net wrote: > not supported by the present standard; it may be worthy of consideration as > a sensible optionally enabled extension; as the use of the combination > "static const" in this context seems fully consistent with the specification It seems like an extension that would not be sensible at all. Type 2 TRs are for experimental features and should be considered as "if you want to do this, it would be a good idea to do it this way; you might find issues through implementation experience which lead to the TR being improved and the subject matter eventually becoming less experimental". So given there's a DTR on this subject, if you want to implement address spaces you should follow the TR and so assist future standardisation rather than implementing some random other extension to do the same thing. We shouldn't go implementing our own new extension to do something there's a standard way to do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20258
[Bug c/20258] error generated for storage class specified for function parameter
--- Additional Comments From schlie at comcast dot net 2005-03-01 22:43 --- Subject: Re: error generated for storage class specified for function parameter > -- Additional Comments From joseph at codesourcery dot com 2005-03-01 > Subject: error generated for storage class specified for function parameter > >> On Tue, 1 Mar 2005, schlie at comcast dot net wrote: >> not supported by the present standard; it may be worthy of consideration as >> a sensible optionally enabled extension; as the use of the combination >> "static const" in this context seems fully consistent with the specification > > It seems like an extension that would not be sensible at all. Type 2 TRs > are for experimental features and should be considered as "if you want to > do this, it would be a good idea to do it this way; you might find issues > through implementation experience which lead to the TR being improved and > the subject matter eventually becoming less experimental". So given > there's a DTR on this subject, if you want to implement address spaces you > should follow the TR and so assist future standardisation rather than > implementing some random other extension to do the same thing. We > shouldn't go implementing our own new extension to do something there's a > standard way to do. Understood. Are you aware of any existing efforts to extend GCC in this way; or likely need to start from scratch? (any warnings/recommendations?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20258
[Bug c/20258] error generated for storage class specified for function parameter
--- Additional Comments From joseph at codesourcery dot com 2005-03-01 22:59 --- Subject: Re: error generated for storage class specified for function parameter On Tue, 1 Mar 2005, schlie at comcast dot net wrote: > Understood. Are you aware of any existing efforts to extend GCC in this way; > or likely need to start from scratch? (any warnings/recommendations?) I am not aware of any existing effort to implement any part of DTR 18037. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20258
[Bug preprocessor/20262] __LINE__ implementation flaky.
--- Additional Comments From neil at daikokuya dot co dot uk 2005-03-01 23:13 --- Subject: Re: __LINE__ implementation flaky. pinskia at gcc dot gnu dot org wrote:- > > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01 > 17:16 --- > Outer Macros are expanded before inner ones and they get all placed on one > line so this is invalid. Huh? This is a bug. The reason it happens is nothing to do with inner or outer macros, but the fact that arguments are collected before being expanded, and an implementation detail where we don't take the line from the token (otherwise __LINE__ would be misexpanded if the RHS of a macro definition) but from the global line counter. It may not be worth fixing; I suspect the reason other implementations fail too is that it's hard to get it right, and the ability to easily do so is heavily dependent on exactly how your preprocessor is implemented. (a bit like the #s vs %:s bug). Neil. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20262
[Bug preprocessor/20262] __LINE__ implementation flaky.
--- Additional Comments From neil at daikokuya dot co dot uk 2005-03-01 23:36 --- Subject: Re: __LINE__ implementation flaky. neil at daikokuya dot co dot uk wrote:- > > --- Additional Comments From neil at daikokuya dot co dot uk 2005-03-01 > 23:13 --- > Subject: Re: __LINE__ implementation flaky. > > pinskia at gcc dot gnu dot org wrote:- > > > > > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01 > > 17:16 --- > > Outer Macros are expanded before inner ones and they get all placed on one > > line so this is invalid. > > Huh? This is a bug. Actually I take that back - I think you can say that the wording of the standard is sufficiently vague that this is not a bug, and may even be correct behaviour. The standard says that (at the time of expansion) it's the "presumed current source line of the file". Since expansion happens after argument collection, it's not hard to argue that the current source line of the file is constant for both __LINE__ tokens. Neil. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20262
[Bug c++/20269] New: Optimizer problem with aliasing floating point variable
gcc -v output:
Reading specs from /opt/gcc-3.4/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: ./configure --prefix=/opt/gcc-3.4 --enable-languages=c,c++
Thread model: posix
gcc version 3.4.3
See following preprocessed output:
extern "C" {
extern void __assert_fail (__const char *__assertion, __const char *__file,
unsigned int __line, __const char *__function)
throw () __attribute__ ((__noreturn__));
}
static void DoTest()
{
double doubleOne = 1.0;
float floatOne = 1.0F;
unsigned int *intDptr = (unsigned int *) &doubleOne;
unsigned int *intFptr = (unsigned int *) &floatOne;
(static_cast (__builtin_expect (!!((intDptr[1] == 0x3ff0) &&
(intDptr[0] == 0)), 1)? 0 : (__assert_fail ("(intDptr[1] == 0x3ff0) &&
(intDptr[0] == 0)", "fptest.cpp", 12, __PRETTY_FUNCTION__), 0)));
(static_cast (__builtin_expect (!!(*intFptr == 0x3f80), 1) ? 0
: (__assert_fail ("*intFptr == 0x3f80", "fptest.cpp", 13,
__PRETTY_FUNCTION__), 0)));
}
int main()
{
DoTest();
}
This compiles fine up to -O1, but with -O2 the test fails. When looking at the
generated assembler it seems to me that the compiler first issues the compare
before putting a value in it. Generated assembler:
gcc -O2 -S -o fptest.S fptest.cpp
main:
.LFB3:
pushl %ebp
.LCFI0:
fld1
movl%esp, %ebp
.LCFI1:
subl$24, %esp
.LCFI2:
andl$-16, %esp
subl$16, %esp
cmpl$1072693248, -4(%ebp)
fstpl -8(%ebp)
jne .L4
movl-8(%ebp), %eax
testl %eax, %eax
jne .L4
leave
xorl%eax, %eax
ret
.p2align 4,,7
.L4:
movl$.LC2, (%esp)
movl$_ZZ6DoTestvE19__PRETTY_FUNCTION__, %ecx
movl$12, %edx
movl%ecx, 12(%esp)
movl$.LC1, %eax
movl%edx, 8(%esp)
movl%eax, 4(%esp)
call__assert_fail
Specifying volatile for all the local variables fixes it.
--
Summary: Optimizer problem with aliasing floating point variable
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bobm75 at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20269
[Bug ada/20270] New: [4.1.0 Regression] Link error: unsatisfied symbols
../../xgcc -B../../ -DIN_GCC `echo -g -O2 -W -Wall -Wwrite-strings -Wstrict-pr ototypes -Wmissing-prototypes -fno-common |sed -e 's/-pedantic//g' -e 's/-Wtradi tional//g'` -o ../../gnatmake b_gnatm.o a-except.o ctrl_c.o ali.o ali-util.o s -casuti.o alloc.o atree.o binderr.o butil.o casing.o csets.o debug.o elists.o ei nfo.o erroutc.o errutil.o err_vars.o fmap.o fname.o fname-uf.o fname-sf.o gnatma ke.o gnatvsn.o hostparm.o interfac.o i-c.o i-cstrin.o krunch.o lib.o make.o make usg.o makeutl.o mlib.o mlib-fil.o mlib-prj.o mlib-tgt.o mlib-utl.o namet.o nlist s.o opt.o osint.o osint-m.o output.o prj.o prj-attr.o prj-attr-pm.o prj-com.o pr j-dect.o prj-env.o prj-err.o prj-ext.o prj-nmsc.o prj-pars.o prj-part.o prj-proc .o prj-strt.o prj-tree.o prj-util.o rident.o s-exctab.o s-secsta.o s-stalib.o s- stoele.o scans.o scng.o sdefault.o sfn_scan.o s-purexc.o s-htable.o sinfo.o sinp ut.o sinput-c.o sinput-p.o snames.o stand.o stringt.o styleg.o stylesw.o system. o validsw.o switch.o switch-m.o table.o targparm.o tempdir.o tree_io.o types.o u intp.o uname.o urealp.o usage.o widechar.o \ ../rts/libgnat.a ../../prefix.o ../../version.o link.o ../../../libiberty /libiberty.a /usr/ccs/bin/ld: Unsatisfied symbols: U_get_unwind_entry (first referenced in ../rts/libgnat.a(s-traceb.o)) (code) U_IS_STUB_OR_CALLX (first referenced in ../rts/libgnat.a(s-traceb.o)) (code) U_get_shLib_text_addr (first referenced in ../rts/libgnat.a(s-traceb.o)) (cod e) U_is_shared_pc (first referenced in ../rts/libgnat.a(s-traceb.o)) (code) U_init_frame_record (first referenced in ../rts/libgnat.a(s-traceb.o)) (code) U_prep_frame_rec_for_unwind (first referenced in ../rts/libgnat.a(s-traceb.o) ) (code) U_get_shLib_unw_tbl (first referenced in ../rts/libgnat.a(s-traceb.o)) (code) U_get_previous_frame_x (first referenced in ../rts/libgnat.a(s-traceb.o)) (co de) U_get_unwind_table (first referenced in ../rts/libgnat.a(s-traceb.o)) (code) collect2: ld returned 1 exit status These symbols are in libcl. -- Summary: [4.1.0 Regression] Link error: unsatisfied symbols Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20270
[Bug c++/20269] Optimizer problem with aliasing floating point variable
--- Additional Comments From bangerth at dealii dot org 2005-03-02 00:04 --- You can't access a floating point variable through a pointer to integer. Read up on -fstrict-aliasing, or its negative -fno-strict-aliasing. W. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20269
[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2
--- Additional Comments From billingd at gcc dot gnu dot org 2005-03-02 00:05 --- and with gfortran 4.1 20040301 at -O2 I get: csep.out: CST drivers: 1 out of 11664 tests failed to pass the threshold csep.out: CST:1 out of 4662 tests failed to pass the threshold ctest.out: CTR: 12 out of 7672 tests failed to pass the threshold ctest.out: CTP: 12 out of 7392 tests failed to pass the threshold ctest.out: CTB: 52 out of 19888 tests failed to pass the threshold dgd.out: DXV drivers:200 out of 5000 tests failed to pass the threshold sgd.out: SXV drivers: 37 out of 5000 tests failed to pass the threshold ssep.out: SST:1 out of 4662 tests failed to pass the threshold ssep.out: SST drivers: 1 out of 14256 tests failed to pass the threshold ssvd.out: SBD: 1 out of 5510 tests failed to pass the threshold zgd.out: ZGV drivers: 66 out of 1092 tests failed to pass the threshold zgd.out: ZXV drivers: 24 out of 5000 tests failed to pass the threshold PR19693 is gone, but there may be a problem with the stest.out routines. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
[Bug c++/19311] [3.4/4.0/4.1 Regression] ICE in resolve_overloaded_unification
--- Additional Comments From giovannibajo at libero dot it 2005-03-02 00:05 --- Mark, what's the status on this? Kriang replied to your review with another patch, but nothing happened since. Can we have either patch approved? http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01007.html http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01332.html -- What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19311
[Bug fortran/19693] optimization problem with LAPACK routine cgtts2.f
--- Additional Comments From billingd at gcc dot gnu dot org 2005-03-02 00:07 --- Fixed by changes to complex divide algorithm. See comment #46 on PR5900 for LAPACK testsuite results at -O2. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19693
[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2
-- Bug 5900 depends on bug 19693, which changed state. Bug 19693 Summary: optimization problem with LAPACK routine cgtts2.f http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19693 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
[Bug java/5537] Error compiling simple bytecode with jsr
--- Additional Comments From bonniot at users dot sf dot net 2005-03-02 00:11 --- What's the take on this bug? Can indirect-dispatch be made the default in the foreseable future? Can the old verifier be fixed? I'm now running nightly builds of gcj on the Nice compiler testsuite (1250 testcases). There are currently 11 failures, and 4 seem to be instances of this verifier bug. So fixing this would be a great improvement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5537
[Bug c++/20269] Optimizer problem with aliasing floating point variable
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-02 00:21 --- This is called a violation of aliasing rules by the way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20269
[Bug ada/20270] [4.1 Regression] Link error: unsatisfied symbols
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||build Summary|[4.1.0 Regression] Link |[4.1 Regression] Link error: |error: unsatisfied symbols |unsatisfied symbols http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20270
[Bug libgcj/20160] [4.0/4.1 Regression] link errors building libgcj tests
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-02 00:27 --- I am going to assume this is fixed so I am going to close as such. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20160
[Bug c++/20269] Optimizer problem with aliasing floating point variable
--- Additional Comments From bobm75 at gmail dot com 2005-03-02 00:33 --- I read the documentation on -fstrict-aliasing and it makes sense to me why this code breaks those rules. I just wonder why the compiler didn't warn about it, since this seems to be a pretty straight forward case of aliasing happening. Thanks for responding so quickly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20269
[Bug ada/20271] New: [4.1.0 Regression] Link error: unsatisfied symbols
../../xgcc -B../../ -DIN_GCC `echo -g -O2 -W -Wall -Wwrite-strings -Wstrict-pr ototypes -Wmissing-prototypes -fno-common |sed -e 's/-pedantic//g' -e 's/-Wtradi tional//g'` -o ../../gnatmake b_gnatm.o a-except.o ctrl_c.o ali.o ali-util.o s -casuti.o alloc.o atree.o binderr.o butil.o casing.o csets.o debug.o elists.o ei nfo.o erroutc.o errutil.o err_vars.o fmap.o fname.o fname-uf.o fname-sf.o gnatma ke.o gnatvsn.o hostparm.o interfac.o i-c.o i-cstrin.o krunch.o lib.o make.o make usg.o makeutl.o mlib.o mlib-fil.o mlib-prj.o mlib-tgt.o mlib-utl.o namet.o nlist s.o opt.o osint.o osint-m.o output.o prj.o prj-attr.o prj-attr-pm.o prj-com.o pr j-dect.o prj-env.o prj-err.o prj-ext.o prj-nmsc.o prj-pars.o prj-part.o prj-proc .o prj-strt.o prj-tree.o prj-util.o rident.o s-exctab.o s-secsta.o s-stalib.o s- stoele.o scans.o scng.o sdefault.o sfn_scan.o s-purexc.o s-htable.o sinfo.o sinp ut.o sinput-c.o sinput-p.o snames.o stand.o stringt.o styleg.o stylesw.o system. o validsw.o switch.o switch-m.o table.o targparm.o tempdir.o tree_io.o types.o u intp.o uname.o urealp.o usage.o widechar.o \ ../rts/libgnat.a ../../prefix.o ../../version.o link.o ../../../libiberty /libiberty.a /usr/ccs/bin/ld: Unsatisfied symbols: U_get_unwind_entry (first referenced in ../rts/libgnat.a(s-traceb.o)) (code) U_IS_STUB_OR_CALLX (first referenced in ../rts/libgnat.a(s-traceb.o)) (code) U_get_shLib_text_addr (first referenced in ../rts/libgnat.a(s-traceb.o)) (cod e) U_is_shared_pc (first referenced in ../rts/libgnat.a(s-traceb.o)) (code) U_init_frame_record (first referenced in ../rts/libgnat.a(s-traceb.o)) (code) U_prep_frame_rec_for_unwind (first referenced in ../rts/libgnat.a(s-traceb.o) ) (code) U_get_shLib_unw_tbl (first referenced in ../rts/libgnat.a(s-traceb.o)) (code) U_get_previous_frame_x (first referenced in ../rts/libgnat.a(s-traceb.o)) (co de) U_get_unwind_table (first referenced in ../rts/libgnat.a(s-traceb.o)) (code) collect2: ld returned 1 exit status These symbols are in libcl. -- Summary: [4.1.0 Regression] Link error: unsatisfied symbols Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20271
[Bug ada/20271] [4.1.0 Regression] Link error: unsatisfied symbols
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-03-02 00:44 --- Subject: Re: New: [4.1.0 Regression] Link error: unsatisfied s Oops, I hit reload. This is a duplicate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20271
[Bug ada/20271] [4.1.0 Regression] Link error: unsatisfied symbols
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-02 00:44 --- I am going to assume you pressed return on accident. *** This bug has been marked as a duplicate of 20270 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20271
