[Bug ada/25117] GNAT Bug Box, GCC error, verify_ssa failed
--- Comment #5 from bauhaus at futureapps dot de 2005-11-29 08:56 --- Created an attachment (id=10359) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10359&action=view) source file set for the 4.1 Bug Box To reproduce, $ cd src $ gcc -c -gnatwecfijkmruv -gnaty3abcefhiklmnoprstx -Wall \ -O2 -gnatn -I- -I../include/ai302 -I../include -I. \ -gnatA aws-containers-key_value.ads -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25117
[Bug libstdc++/11953] _REENTRANT defined when compiling non-threaded code.
--- Comment #35 from marc dot waeckerlin at siemens dot com 2005-11-29 09:13 --- I had a look in google about "#ifdef _REENTRANT", and it gets about 20'200 entries, so this is a widely used funtinality that must not be broken! Imagine all the code the does the "#ifdef _REENTRANT" to enable threading: If now _REENTRANT is always true, regardless of whether -pthreads is given or not, then all this code will crash when compiled with gcc += 3.4! This is really a severe problem! Please return to the previous behaviour of _REENTRANT, and fix it for those platforms, where it previousely did not work (s390x and ia64). The _REENTRANT must work as 90% of the programmers expect it to work! It wasn't my idea to look for _REENTRANT, i learnt it from a collegue who has seen it in system C libraries and e.g. the QpThread library. It is a widely used feature! It must neither be broken, nor be replaced by something else, sich as __GCC_PTHREADS__ or the like! In errno.h, AFAIK they also tested for _REENTRANT, now they test for: # if !defined _LIBC || defined _LIBC_REENTRANT Is this an acceptable way to do it now, test for _LIBC_REENTRANT? Reentrant is also used in /usr/include/features.h: /* These are defined by the user (or the compiler) to specify the desired environment: [...] _REENTRANT Select additionally reentrant object. _THREAD_SAFE Same as _REENTRANT, often used by other systems. [...] */ --> So it should be set correctly by the compiler #if defined _REENTRANT || defined _THREAD_SAFE # define __USE_REENTRANT1 #endif -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953
[Bug libstdc++/11953] _REENTRANT defined when compiling non-threaded code.
--- Comment #36 from marc dot waeckerlin at siemens dot com 2005-11-29 09:27 --- New information: _REENTRANT is definitively defined in the headers: > echo "" | g++ \ -I /usr/include/c++/4.0.2 -I /usr/include/c++/4.0.2/i586-suse-linux \ -E -dM -c - | grep REENTRANT > echo "" | g++ \ -I /usr/include/c++/4.0.2 -I /usr/include/c++/4.0.2/i586-suse-linux \ -E -dM -c -pthread - | grep REENTRANT #define _REENTRANT 1 > echo "#include" | g++ \ -I /usr/include/c++/4.0.2 -I /usr/include/c++/4.0.2/i586-suse-linux \ -E -dM -c - | grep REENTRANT #define _REENTRANT 1 #define _POSIX_REENTRANT_FUNCTIONS 1 --> So, without "#include " it works as expected! This opens a new possibility to work around this bug: --file.cpp #define GCC_BUGFIX _REENTRANT #include #include ... #undef _REENTRANT #define _REENTRANT GCC_BUGFIX #ifdef _REENTRANT ... #endif -- > g++ -v Using built-in specs. Target: i586-suse-linux Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,f95,java,ada --disable-checking --with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-java-awt=gtk --disable-libjava-multilib --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --without-system-libunwind --host=i586-suse-linux Thread model: posix gcc version 4.0.2 20050901 (prerelease) (SUSE Linux) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953
[Bug ada/25117] GNAT Bug Box, GCC error, verify_ssa failed
--- Comment #6 from bauhaus at futureapps dot de 2005-11-29 09:30 --- Created an attachment (id=10360) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10360&action=view) source file set for the 4.2 Bug Box To reproduce, $ cd src $ gcc -c -gnatwecfijkmruv -gnaty3abcefhiklmnoprstx -Wall \ -O2 -gnatn -I- -gnatA -I../include/ai302 -I../include -I. \ aws-attachments.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25117
[Bug libstdc++/11953] _REENTRANT defined when compiling non-threaded code.
--- Comment #37 from marc dot waeckerlin at siemens dot com 2005-11-29 09:33 --- Correction: The above work around only works, as long, as your file is not included by another file... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953
[Bug libfortran/25017] sqrt, csqrt may give a wrong result if real part of compex argument is zero
--- Comment #7 from harald dot vogt at desy dot de 2005-11-29 09:42 --- (In reply to comment #6) > Subject: Re: sqrt, csqrt may give a wrong result if real part of compex > argument is zero > > On Thu, Nov 24, 2005 at 05:05:12PM -, pinskia at gcc dot gnu dot org > wrote: > > > > (In reply to comment #4) > > > c99_functions.c contains implementations of csqrt[fl], > > > which are the fixed glibc routines. We can remove > > > the "#if !defined(HAVE_CSQRTF)" and simply have gfortran > > > use its own versions. > > > > For only targets which have a broken csqrtf yes. Please don't do it all the > > time. > > > > I've never used glibc. Does it define a _GLIBC_VERSION_MAJOR > and _GLIBC_VERSION_MINOR? We could do > > #if !defined(HAVE_CSQRTF) || (xx_MAJOR < 42 & xx_MINOR < 42) > Dont rely on the glibc version. The better way should be to use libgfortran/configure for csqrt, csqrtf, csqrtl to check them and setting HAVE_CSQRT, HAVE_CSQRTF, HAVE_CSQRTL if the checks will not fail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25017
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #39 from pcarlini at suse dot de 2005-11-29 10:24 --- Eric, I'm sorry, any news?!? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug fortran/25084] Interface for assumed length character function allowed
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-29 11:21 --- Confirmed. Reminds a bit of PR 24705, except here we have an interface only. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2005-11-29 11:21:56 date|| Summary|better diagnostic needed|Interface for assumed length ||character function allowed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25084
[Bug middle-end/24804] [3.4 Regression] Produces wrong code
--- Comment #7 from reichelt at gcc dot gnu dot org 2005-11-29 11:26 --- The command line flags "-O -fgcse" are sufficient to reproduce the bug. The constructor of DummyType can be omitted. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Keywords||monitored http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24804
[Bug fortran/25085] Array valued assumed length character function allowed
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-29 11:27 --- Confirmed. Reminds a bit of PR 24705. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2005-11-29 11:27:03 date|| Summary|better diagnostic needed|Array valued assumed length ||character function allowed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25085
[Bug fortran/25086] Pointer valued assumed length character function allowed
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-29 11:30 --- Confirmed. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2005-11-29 11:30:29 date|| Summary|better diagnostic needed|Pointer valued assumed ||length character function ||allowed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25086
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #40 from ebotcazou at gcc dot gnu dot org 2005-11-29 11:51 --- > Eric, I'm sorry, any news?!? Thanks. Bootstrap was broken last week and I was away for the week-end... I'll need to re-compute baseline results first, so maybe at the end of this week. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug fortran/25087] better diagnostic needed
--- Comment #2 from eedelman at gcc dot gnu dot org 2005-11-29 12:00 --- Reduced testcase: SUBROUTINE s(n) CHARACTER(LEN=n), EXTERNAL :: a write(6,*) a(n) END SUBROUTINE s The problem, unless I'm missing something, is that the external function a would need an explicit interface. From the draft F2003 standard, 12.3.1.1: "A procedure [...] shall have an explicit interface if it is referenced and -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25087
[Bug fortran/25087] Error for missing explicit interface needed.
--- Comment #3 from eedelman at gcc dot gnu dot org 2005-11-29 12:06 --- (In reply to comment #2) > Reduced testcase: > > SUBROUTINE s(n) > CHARACTER(LEN=n), EXTERNAL :: a > write(6,*) a(n) > END SUBROUTINE s > > The problem, unless I'm missing something, is that the external function a > would need an explicit interface. From the draft F2003 standard, 12.3.1.1: > > "A procedure [...] shall have an explicit interface if it is referenced and > Sorry, I messed up. Here's what I intended to write: "A procedure [...] shall have an explicit interface if it is referenced and [...] (3) The procedure has a result that [...] (c) has a nonassumed type parameter value that is not an initialization expression" Ifort 8.1 gives the following error message for this code: beam:~$ ifort huj.f90 fortcom: Error: huj.f90, line 2: This passed length character name has been used in an invalid context. [A] CHARACTER(LEN=n), EXTERNAL :: a ---^ -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2005-11-29 12:06:22 date|| Summary|better diagnostic needed|Error for missing explicit ||interface needed. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25087
[Bug libfortran/25139] "Invalid argument" error on I/O
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2005-11-29 12:12 --- Well, since it relies on uninitialized variables, it's a bit hard to reproduce. The following code (I believe it is legal) reproducibly fails for me on i686-linux: integer dat(5) dat = (/ 0, 0, 0, 0, 18651460 /) write(11) dat,dat,dat rewind 11 write(11) dat,dat,dat,dat rewind 11 write(11) dat rewind 11 write(11) dat rewind 11 read(11) dat read(11,end=1008) dat 1008 continue backspace 11 write(11) dat backspace 11 read(11) dat read(11,end=1011) dat 1011 continue backspace 11 backspace 11 end I think it has to do with array transfer, and overwriting the record markes with data. Adding Janne in CC list for opinion. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||jb at gcc dot gnu dot org, ||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|powerpc-apple-darwin8.3.0 | Last reconfirmed|-00-00 00:00:00 |2005-11-29 12:12:42 date|| Summary|Fortran runtime error: |"Invalid argument" error on |Invalid argument|I/O http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25139
[Bug libfortran/25139] "Invalid argument" error on I/O
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2005-11-29 12:29 --- The testcase can be reduced further: integer dat(5) dat = (/ 0, 0, 0, 0, 1 /) write(11) dat,dat,dat,dat rewind 11 write(11) dat read(11,end=1008) dat 1008 continue backspace 11 write(11) dat read(11,end=1011) dat 1011 continue backspace 11 backspace 11 end At line 13 of file testio2.f Fortran runtime error: Invalid argument >From looking at the fort.11 file, I think the output is correct at every point of the program. Also note that if we comment two lines of this testcase, like that: integer dat(5) dat = (/ 0, 0, 0, 0, 1 /) write(11) dat,dat,dat,dat rewind 11 write(11) dat read(11,end=1008) dat 1008 continue ! backspace 11 ! write(11) dat read(11,end=1011) dat 1011 continue backspace 11 backspace 11 end then we get another error message (which shouldn't happen): At line 10 of file testio2.f Fortran runtime error: Read past ENDFILE record I don't know yet if these bugs have the same cause. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-11-29 12:12:42 |2005-11-29 12:29:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25139
[Bug libfortran/25017] sqrt, csqrt may give a wrong result if real part of compex argument is zero
--- Comment #8 from sgk at troutmask dot apl dot washington dot edu 2005-11-29 12:47 --- Subject: Re: sqrt, csqrt may give a wrong result if real part of compex argument is zero On Tue, Nov 29, 2005 at 09:42:05AM -, harald dot vogt at desy dot de wrote: > > > Comment #7 from harald dot vogt at desy dot de 2005-11-29 09:42 --- > > > > I've never used glibc. Does it define a _GLIBC_VERSION_MAJOR > > and _GLIBC_VERSION_MINOR? We could do > > > > #if !defined(HAVE_CSQRTF) || (xx_MAJOR < 42 & xx_MINOR < 42) > > > > Dont rely on the glibc version. The better way should be to use > libgfortran/configure for csqrt, csqrtf, csqrtl to check them and setting > HAVE_CSQRT, HAVE_CSQRTF, HAVE_CSQRTL if the checks will not fail. > Do you have a patch? Because I have no idea want you mean. libgfortran/configurei already checks for the existence of these functions. glibc's are broken in the release, but are fixed in cvs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25017
[Bug c++/25152] New: -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing
the attached program generates wrong code with -O -fstrict-aliasing (-O works), although -Wstrict-aliasing doesn't issue a warning. The bug was not present in gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) (the generated code was OK even with -O3). The bug is present in : - gcc version 4.0.1 20050727 (Red Hat 4.0.1-5) - gcc 4.0.2 - gcc version 4.1.0 20051128 (prerelease) gcc-4_1-branch gcc version 4.2.0 20051128 (experimental) issues the warning, and generates the right code with -O2 -fstrict-aliasing, though it breaks with -O3. My conclusion is that gcc 4.2 doesn't have this bug. IMHO this is critical, since it's a regression from 3.3, and gcc generates wrong code without the user being warned. Fred -- Summary: -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: frederic dot devernay at m4x dot org GCC build triplet: i386-redhat-linux GCC host triplet: i386-redhat-linux GCC target triplet: i386-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25152
[Bug c++/25152] -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing
--- Comment #1 from frederic dot devernay at m4x dot org 2005-11-29 13:30 --- Created an attachment (id=10361) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10361&action=view) test case this source generates wrong code without issueing a warning, using: g++ -DMAIN -O -Wstrict-aliasing -fstrict-aliasing cxcopy-preproc.cpp -o testcase it generates the right code with: g++ -DMAIN -O cxcopy-preproc.cpp -o testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25152
[Bug target/24842] testsuite failure: gcc.dg/attr-weakref-1.c execution test
--- Comment #3 from aoliva at gcc dot gnu dot org 2005-11-29 13:50 --- Sorry, I totally misread the testsuite output. Can you tell what part of the execution test that fails? I find it very unlikely that this is a compiler error; it's far more likely to be a linker failure to handle weak symbols properly, unless there's something very peculiar about the way this target handles weak symbols. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24842
[Bug middle-end/25140] aliases, including weakref, break alias analysis
--- Comment #4 from aoliva at gcc dot gnu dot org 2005-11-29 13:55 --- Make it a weak alias, then. Anyhow, the point is that the alias infrastructure in GCC is available for all ports. If some port limits what kinds of aliases you can use, then, well, too bad. But the smarts to get alias analysis to follow symbol aliases is missing for all kinds of aliases, not only weakrefs, and the good news is that fixing it for regular and weak aliases will fix it for weakrefs as well, unless you try really hard to keep weakrefs broken just to make a point :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25140
[Bug testsuite/19231] Execute failure in gcc.c-torture/execute/builtins/strlen-3.c with -fpic/-fPIC
--- Comment #3 from ghazi at gcc dot gnu dot org 2005-11-29 13:55 --- Fixed by: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01889.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19231
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #41 from pcarlini at suse dot de 2005-11-29 14:00 --- Ok, agreed. I'm eager to finally close the oldest open libstdc++ PR... ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug target/19227] [3.4 only] Error in gcc.c-torture/compile/20000804-1.c when using -fpic/-fPIC on i686-pc-linux-gnu
--- Comment #2 from ghazi at gcc dot gnu dot org 2005-11-29 14:03 --- Fixed in 4.0.3 and later by: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01889.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19227
[Bug target/24842] testsuite failure: gcc.dg/attr-weakref-1.c execution test
--- Comment #4 from hp at gcc dot gnu dot org 2005-11-29 14:08 --- Yes, it may be a linker error. This target uses the generic linker machinery (since linking from ELF to mmo), which is not exactly the hot-path for other targets. I know of no particular way of telling *which* part of the test that failed, without looking at the simulator trace of course, which I'll do when I get to looking at this myself. (Which anyone can do anyway before that; just install the simulator and start printf-ing.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24842
[Bug testsuite/19275] [3.4/4.0] gcc.dg/20020919-1.c fails with -fpic/-fPIC on i686-pc-linux-gnu
--- Comment #5 from ghazi at gcc dot gnu dot org 2005-11-29 14:25 --- These two patches fixed the problem on mainline/4.1 and need to be backported: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02322.html http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02828.html I'll do it after testing. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ghazi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-11-03 17:09:40 |2005-11-29 14:25:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19275
[Bug target/24831] [4.1/4.2 regression] gthr-dce.h:77: error: expected expression before '{' token
--- Comment #9 from aoliva at gcc dot gnu dot org 2005-11-29 14:27 --- Created an attachment (id=10362) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10362&action=view) Tentative patch to accomodate expressions, absent functions et al Dave, could you please give this patch a try? I haven't tested it yet, but I think the approach is promising. It certainly conflicts with your patch. I've tried to merge the essential bits from it (i.e., the UNUSED changes are not in). Sorry for taking so long to get to this, I've been away for most of last week. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24831
[Bug c++/25153] New: Bug in name lookup in template -- 4.0 regression against 3.4
The code below compiles fine with gcc 3.3.1 and 3.4.0 (and does the right
thing); it produces a compile time error in 4.0.2. Lookup of the << operator
in the definition of serializable::impl::value fails when it is instatiated
via the bar or baz templates but succeeds when instantiated via the foo
template. (Use of the bar or baz templates will succeed if instantation has
alread occured.)
Curiously, the bug seems very specific -- a number of very similar pieces of
code in 4.0.2's header compile correctly.
//
extern "C" int printf( char const*, ... );
namespace std2 {
class ostream { void* ptr; };
class string;
ostream& operator<<( ostream&, string const& );
}
namespace serializable {
struct two { std2::ostream a, b; };
template two operator<<(U&, V const&);
template
struct impl {
static T const& make();
static std2::ostream& stream();
static const bool value
= sizeof( stream() << make() ) == sizeof(std2::ostream);
};
}
template struct foo { foo() { printf("%d\n", V); } };
template struct baz : foo< T::value > {};
template struct bar : baz< serializable::impl > {};
struct X {};
int main() {
bar< X >(); // -- Fails
baz< serializable::impl >(); // -- Fails
foo< serializable::impl::value >(); // -- Succeeds
baz< serializable::impl >(); // -- Succeeds
bar< X >(); // -- Succeeds
}
// Expected output: 0 0 0 0 0
--
Summary: Bug in name lookup in template -- 4.0 regression against
3.4
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: richard at ex-parrot dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25153
[Bug c++/25152] -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-29 15:12 ---
4.2 warns:
t.cc: In function 'CvStatus icvSet_8u_C4MR(int*, int, const uchar*, int,
CvSize, const int*)':
t.cc:21: warning: dereferencing type-punned pointer will break strict-aliasing
rules
Because the warning was not in 4.1.0 at all for C++.
This is invalid as:
CvStatus
icvSet_8u_C4MR (int *dst, int step, const uchar * mask, int step2,
CvSize size, const int *scalar)
{
int s0 = scalar[0];
for (; size.height--; mask += step2, (char *&) dst += step)
{
"(char *&) dst += step" is equaliant to *((char**)&dst) += step
so we are accessing dst as a "char*" which violates alaiasing rules.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25152
[Bug c++/25153] [4.0 Regression] Bug in name lookup in template -- 4.0 regression against 3.4
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-29 15:19 --- Fixed in 4.0.3 already. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Summary|Bug in name lookup in |[4.0 Regression] Bug in name |template -- 4.0 regression |lookup in template -- 4.0 |against 3.4 |regression against 3.4 Target Milestone|--- |4.0.3 Version|unknown |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25153
[Bug libobjc/24775] libobjc should not include GCC's target headers
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-29 16:01 --- A start is done on the branch libobjc_noheaders. I almost forgot about thrd-objc.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24775
[Bug c/25155] New: Base type of expressions involving short operands is shown as int
I don't know whether it is a bug or not.
Consider the following example:
short int sh1 = 1;
short int sh2 = 2;
printf("Size of short: %d\n", sizeof(short));
printf("Size of int: %d\n", sizeof(int));
printf("Size of expr: %d\n", sizeof(sh1+sh2));
Output:
Size of short: 2
Size of int: 4
Size of expr: 4
GCC is converting short to int while doing any arithmatic operation. Can anyone
explain why it is happening and where exactly(function) does this conversion
happen?
--
Summary: Base type of expressions involving short operands is
shown as int
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: santhosh dot selvaraj at wipro dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25155
[Bug libstdc++/11953] _REENTRANT defined when compiling non-threaded code.
--- Comment #38 from carlo at gcc dot gnu dot org 2005-11-29 16:05 --- That never works because it always defines _REENTRANT. You probably mean: #ifdef _REENTRANT #define GCC_BUGFIX 1 #endif #include #undef _REENTRANT #ifdef GCC_BUGFIX #define _REENTRANT 1 #endif The drawback of this "fix" is that it is hardly usable for library writers like you and me. You can add this to every .cpp file of an application, but it doesn't help to determine if the _user_ (of your library) wants thread-safeness or not. Such a user will add -pthread when compiling his application but we cannot detect that anymore. We can also not demand that users of our library add the above kludge at the top of every .cpp file of their application (before any system headers are included) or, equivalently, demand they include the header of our library before any system header. That being said, I obviously agree completely with Marc that this is a bug: _REENTRANT should only be defined by the compiler iff -pthread is passed to the compiler. I know that is not a written standard, but it certainly is widely used and something developers have come to rely on so much that it is pure arrogance to break it. I'd say, ignorance-- but given the fact that I reported this BEFORE it was released (after running into it in a cvs version), and it was released anyway... Nevertheless-- I've seen enough of the gcc development (that is, what is related with C++) to know that 'we' cannot rely on (the) g++ (developers) being interested in keeping backwards compatibility with ANYTHING that isn't set in stone by some ISO committee (refering to some GNU extensions here). Therefore I suggest to everyone reading this: don't rely on common sense. The define of _REENTRANT isn't some standard and therefore you cannot not rely on it (when using g++). Even if it was fixed in 4.1, you can count on it being broken again in 4.2. The only reliable "solution" left is to demand that the users define a macro on the command line. So, expect to see this kind of compilations in the future: g++ -pthread -DBOOST_THREAD_SAFE -DLIBCWD_THREAD_SAFE -DLIBXML2_THREAD_SAFE -DLIBC_THREAD_SAFE -DLIBFOO_THREAD_SAFE -DLIBGTK_THREAD_SAFE [...] application.cc until some guru proposes that all libraries make use of one and the same define: GURU_THREAD_SAFE. Unfortunately... two decades later, once that macro made it's way into AX[3.4]UbuOS-6.8 and some bug needs it to be defined always... g++ will think it's allowed to unconditionally define GURU_THREAD_SAFE too... because it wasn't an official standard [...] Yeah, history repeats itself. Watch and see. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953
[Bug c++/25156] New: wrong error message (int instead of bool)
bool func()
{
return;
}
a.cc:3: error: return-statement with no value, in function returning 'int'
--
Summary: wrong error message (int instead of bool)
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25156
[Bug c/25155] Base type of expressions involving short operands is shown as int
--- Comment #1 from schwab at suse dot de 2005-11-29 16:13 --- This is the effect of the integer promotion rules. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25155
[Bug c++/25156] [3.4/4.0/4.1 Regression] wrong error message (int instead of bool)
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-29 16:40 --- Confirmed, all an integer types give the wrong error (well except for int). 3.3 gave: t.c: In function `bool func()': t.c:3: error: return-statement with no value, in function declared with a non-void return type So this is a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Known to fail||3.4.0 4.0.0 4.1.0 Last reconfirmed|-00-00 00:00:00 |2005-11-29 16:40:35 date|| Summary|wrong error message (int|[3.4/4.0/4.1 Regression] |instead of bool)|wrong error message (int ||instead of bool) Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25156
[Bug c++/25156] [3.4/4.0/4.1 Regression] wrong error message (int instead of bool)
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-29 16:46 --- Hmm, it is looking at the wrong type, it is looking at the RESULT_DECL's type instead of the FUNCTION_TYPE's type which has the correct type, I might fix this later tonight. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25156
[Bug java/25040] gcjh generated .h files missing methods inherited from interfaces
--- Comment #2 from tromey at gcc dot gnu dot org 2005-11-29 17:09 --- *** This bug has been marked as a duplicate of 15411 *** -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25040
[Bug java/15411] CNI: gcjh not aware of "miranda" methods
--- Comment #4 from tromey at gcc dot gnu dot org 2005-11-29 17:09 --- *** Bug 25040 has been marked as a duplicate of this bug. *** -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||michele at focuseek dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15411
[Bug libgcj/25016] Integer overflow in _Jv_CondWait
--- Comment #7 from tromey at gcc dot gnu dot org 2005-11-29 17:13 --- Fix checked in everywhere. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25016
[Bug tree-optimization/25145] missed VRP opportunity
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-29 17:34 ---
(In reply to comment #5)
> Note this was the simple fix which exposes those latent bugs as far as I can
> see that should work, we get the correct range but the rest of VRP goes
> bonkers:
I should also note it does not do the correct thing for -fwrapv either.
For the testcase in comment #1:
int f(int i, int j )
{
int k;
k = i+ - 1;
return k < i;
}
i = INT_MIN
k will equal INT_MAX so the comparision will be wrong to return true as INT_MAX
is not less than INT_MIN.
VRP does not like symbolic ranges at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25145
[Bug tree-optimization/25148] compare_values assumes that CST in a + CST (and a - CST) is always postive
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-29 17:36 --- I should also note that compare_values is does not respect -fwrapv either as shown by the testcase in PR 25145 in comment #1 and comment #6. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25148
[Bug c++/25152] -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing
--- Comment #3 from frederic dot devernay at m4x dot org 2005-11-29 17:42 --- I know it breaks aliasing rules, but this problem was not present in gcc-3.3. Most gcc users consider "-O2" as being a safe optimizing option, (e.g. redhat RPMs are compiled with gcc -O2), and generating wrong code from proper ISO C++ source without even a warning looks like a regression to me. FYI, this bug came out when compiling OpenCV (maintained and distributed by Intel) on Fedora Core 4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25152
[Bug c++/25152] -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-29 17:47 --- (In reply to comment #3) > I know it breaks aliasing rules, but this problem was not present in gcc-3.3. So ... GCC 4.1 includes more optimization than 3.3 did which takes advantage of the aliasing rules. Note this is only undefined behavior. There are lots of undefined behavior which we don't warn about. An example is signed overflow, if we warned about that it would show up in the simple i++ or i = a + b example. The warning was a bug which was filed a long time ago and was just only fixed. Also I should note different targets would show up aliasing violating differently. PPC will show more than x86 since the scheduler uses the information and PPC relies more and than the shceduler than x86 does. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25152
[Bug c++/25156] [3.4/4.0/4.1 Regression] wrong error message (int instead of bool)
--- Comment #3 from gdr at integrable-solutions dot net 2005-11-29 17:48 --- Subject: Re: [3.4/4.0/4.1 Regression] wrong error message (int instead of bool) "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Hmm, it is looking at the wrong type, it is looking at the RESULT_DECL's type | instead of the FUNCTION_TYPE's type which has the correct type, I might fix | this later tonight. That is a combination of two things: (1) vestige of the old infamous named-returned value extension logic; (2) the default widening-strategy used in the compiler. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25156
[Bug c++/25152] -fstrict-aliasing generates wrong code, but no warning from -Wstrict-aliasing
--- Comment #5 from bonzini at gnu dot org 2005-11-29 17:55 --- Frederic, "-Wstrict-aliasing" is only working for C up until 4.1 (included). Your code, rewritten to C, would issue a warning with 4.1 and earlier compilers as well. Also note that -Wstrict-aliasing does not prevent the compiler from using aliasing relationships that it has warned about. GCC 4.2 has the same behavior as earlier versions, just does not expose it by generating wrong results, maybe because it finds some more interesting optimization to do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25152
[Bug c++/25156] [3.4/4.0/4.1 Regression] wrong error message (int instead of bool)
--- Comment #4 from gdr at integrable-solutions dot net 2005-11-29 18:02 --- Subject: Re: [3.4/4.0/4.1 Regression] wrong error message (int instead of bool) "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Hmm, it is looking at the wrong type, it is looking at the RESULT_DECL's type | instead of the FUNCTION_TYPE's type which has the correct type, I might fix | this later tonight. Try this *** ChangeLog (revision 107674) --- ChangeLog (local) *** *** 1,3 --- 1,10 + 2005-11-29 Gabriel Dos Reis <[EMAIL PROTECTED]> + + PR c++/25156 + * typeck.c (check_return_expr): Get the return-type from the + function declaration, now that the named-return value extension is + no longer existent. + 2005-11-30 Ben Elliston <[EMAIL PROTECTED]> * typeck.c (build_x_unary_op): Correct spelling in error message. *** typeck.c(revision 107674) --- typeck.c(local) *** check_return_expr (tree retval, bool *no *** 6257,6270 return retval; } ! /* When no explicit return-value is given in a function with a named ! return value, the named return value is used. */ ! result = DECL_RESULT (current_function_decl); ! valtype = TREE_TYPE (result); gcc_assert (valtype != NULL_TREE); fn_returns_value_p = !VOID_TYPE_P (valtype); - if (!retval && DECL_NAME (result) && fn_returns_value_p) - retval = result; /* Check for a return statement with no return value in a function that's supposed to return a value. */ --- 6257,6269 return retval; } ! /* We no longer support the old "named-return value" extension, so get ! the return-type from the function declaration. */ ! valtype = TREE_TYPE (TREE_TYPE (current_function_decl)); gcc_assert (valtype != NULL_TREE); + result = DECL_RESULT (current_function_decl); + gcc_assert (TREE_TYPE (result) != 0); fn_returns_value_p = !VOID_TYPE_P (valtype); /* Check for a return statement with no return value in a function that's supposed to return a value. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25156
[Bug other/25157] New: /libdecnumber/decContext.h:43:49: stdint.h: No such file or directory
make[1]: Entering directory `/xxx/gnu/gcc-3.3/objdir/libdecnumber' source='../../gcc/libdecnumber/decNumber.c' object='decNumber.o' libtool=no gcc -I../../gcc/libdecnumber -I. -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototyp es -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedan tic -Wno-long-long -I../../gcc/libdecnumber -I. -c ../../gcc/libdecnumber/decN umber.c In file included from ../../gcc/libdecnumber/decNumber.h:30, from ../../gcc/libdecnumber/decNumber.c:156: ../../gcc/libdecnumber/decContext.h:43:49: stdint.h: No such file or directory make[1]: *** [decNumber.o] Error 1 -- Summary: /libdecnumber/decContext.h:43:49: stdint.h: No such file or directory Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa1.1-hp-hpux10.20 GCC host triplet: hppa1.1-hp-hpux10.20 GCC target triplet: hppa1.1-hp-hpux10.20 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25157
[Bug middle-end/25158] New: FAIL: gcc.c-torture/execute/builtins/fprintf.c compilation
At all optimizations: Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/xgcc -B/mnt/gnu/gcc-3.3/objdir/gc c/ /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/fprintf.c / mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/fprintf-lib.c / mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c -w -O0 -fno-show-column -lm -o /mnt/gnu/gcc-3.3/objdir/gcc/testsuite/fprintf.x 0(timeout = 300) /usr/bin/ld: Unsatisfied symbols: fputs_unlocked (first referenced in /var/tmp//ccgYoZcc.o) (code) collect2: ld returned 1 exit status compiler exited with status 1 output is: /usr/bin/ld: Unsatisfied symbols: fputs_unlocked (first referenced in /var/tmp//ccgYoZcc.o) (code) collect2: ld returned 1 exit status FAIL: gcc.c-torture/execute/builtins/fprintf.c compilation, -O0 UNRESOLVED: gcc.c-torture/execute/builtins/fprintf.c execution, -O0 -- Summary: FAIL: gcc.c-torture/execute/builtins/fprintf.c compilation Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin 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=25158
[Bug middle-end/25159] New: FAIL: gcc.c-torture/execute/builtins/fputs.c execution
At -O1, -O2 and -O3: Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/xgcc -B/mnt/gnu/gcc-3.3/objdir/gc c/ /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/fputs.c /mn t/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/fputs-lib.c /mnt/ gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c -w -O1 -fno-show-column -lm -o /mnt/gnu/gcc-3.3/objdir/gcc/testsuite/fputs.x1 ( timeout = 300) PASS: gcc.c-torture/execute/builtins/fputs.c compilation, -O1 Setting LD_LIBRARY_PATH to :/mnt/gnu/gcc-3.3/objdir/gcc::/mnt/gnu/gcc-3.3/objdir /gcc byehello world worldd hello hello FAIL: gcc.c-torture/execute/builtins/fputs.c execution, -O1 -- Summary: FAIL: gcc.c-torture/execute/builtins/fputs.c execution Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin 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=25159
[Bug java/25021] Can't compile ant 1.6.5 to machine code
--- Comment #2 from tromey at gcc dot gnu dot org 2005-11-29 18:31 --- In the version of ant I have (1.6.2) the class is org.apache.tools.ant.launch.Launcher not org.apache.tools.ant.launcher.Launcher So I think this is just a typo in the --main argument. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25021
[Bug java/18278] JNI functions cannot return a weak reference
--- Comment #8 from tromey at gcc dot gnu dot org 2005-11-29 18:35 --- Subject: Bug 18278 Author: tromey Date: Tue Nov 29 18:34:58 2005 New Revision: 107676 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107676 Log: gcc/java: PR java/18278: * expr.c (build_jni_stub): Unwrap the return value. * java-tree.h (soft_unwrapjni_node): New define. (enum java_tree_index): Added JTI_SOFT_UNWRAPJNI_NODE. * decl.c (java_init_decl_processing): Initialize soft_unwrapjni_node. libjava: PR java/18278: * testsuite/libjava.jni/pr18278.out: New file. * testsuite/libjava.jni/pr18278.c: New file. * testsuite/libjava.jni/pr18278.java: New file. * include/jvm.h (_Jv_UnwrapJNIweakReference): Declare. * jni.cc (_Jv_UnwrapJNIweakReference): New function. (call): Unwrap return value if needed. Added: trunk/libjava/testsuite/libjava.jni/pr18278.c trunk/libjava/testsuite/libjava.jni/pr18278.java trunk/libjava/testsuite/libjava.jni/pr18278.out Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/decl.c trunk/gcc/java/expr.c trunk/gcc/java/java-tree.h trunk/libjava/ChangeLog trunk/libjava/include/jvm.h trunk/libjava/jni.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18278
[Bug c++/24996] [4.0/4.1/4.2 Regression] ICE on throw code
--- Comment #4 from janis at gcc dot gnu dot org 2005-11-29 18:36 --- A regression hunt identified the following patch (not terribly useful): r81764 | dnovillo | 2004-05-13 06:41:07 + (Thu, 13 May 2004) | 3 lines Merge tree-ssa-20020619-branch into mainline. Andrew, are you sure about 3.4.0 crashing for this testcase? I tried mainline as far back as 2003-03-08 at regular intervals and saw no failures before the tree-ssa merge. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24996
[Bug c++/24996] [4.0/4.1/4.2 Regression] ICE on throw code
--- Comment #5 from janis at gcc dot gnu dot org 2005-11-29 18:37 --- The question in my previous comment should have been to Volker, not Andrew. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24996
[Bug libfortran/25139] "Invalid argument" error on I/O
--- Comment #4 from jb at gcc dot gnu dot org 2005-11-29 18:37 --- It doesn't have anything to do with array transfers. The following test program is equivalent to the one in #3, but uses the scalar transfer_integer instead of transfer_array: program test3 integer dat(5) dat = (/ 1, 2, 3, 4, 5 /) write(11) dat(1), dat(2), dat(3), dat(4), dat(5), & dat(1), dat(2), dat(3), dat(4), dat(5), & dat(1), dat(2), dat(3), dat(4), dat(5), & dat(1), dat(2), dat(3), dat(4), dat(5) rewind 11 write(11) dat(1), dat(2), dat(3), dat(4), dat(5) read(11,end=1008) dat(1), dat(2), dat(3), dat(4), dat(5) 1008 continue backspace 11 write(11) dat(1), dat(2), dat(3), dat(4), dat(5) read(11,end=1011) dat(1), dat(2), dat(3), dat(4), dat(5) 1011 continue backspace 11 backspace 11 end program test3 Depending on whether the two lines after 1008 continue are commented or not, it shows the same errors as the ones in #3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25139
[Bug c++/24996] [4.0/4.1/4.2 Regression] ICE on throw code
--- Comment #6 from reichelt at igpm dot rwth-aachen dot de 2005-11-29 18:44 --- Subject: Re: [4.0/4.1/4.2 Regression] ICE on throw code On 29 Nov, janis at gcc dot gnu dot org wrote: > Andrew, are you sure about 3.4.0 crashing for this testcase? I tried mainline > as far back as 2003-03-08 at regular intervals and saw no failures before the > tree-ssa merge. I can see the failure in 3.4.0 on i686-pc-linux-gnu and x86_64-unknown-linux-gnu. This is a segfault, however, and therefore probably caused a different problem. Regards, Volker -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24996
[Bug java/18278] JNI functions cannot return a weak reference
--- Comment #9 from tromey at gcc dot gnu dot org 2005-11-29 18:58 --- Subject: Bug 18278 Author: tromey Date: Tue Nov 29 18:58:23 2005 New Revision: 107677 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107677 Log: gcc/java: PR java/18278: * expr.c (build_jni_stub): Unwrap the return value. * java-tree.h (soft_unwrapjni_node): New define. (enum java_tree_index): Added JTI_SOFT_UNWRAPJNI_NODE. * decl.c (java_init_decl_processing): Initialize soft_unwrapjni_node. libjava: PR java/18278: * testsuite/libjava.jni/pr18278.out: New file. * testsuite/libjava.jni/pr18278.c: New file. * testsuite/libjava.jni/pr18278.java: New file. * include/jvm.h (_Jv_UnwrapJNIweakReference): Declare. * jni.cc (_Jv_UnwrapJNIweakReference): New function. (call): Unwrap return value if needed. Added: branches/gcc-4_1-branch/libjava/testsuite/libjava.jni/pr18278.c branches/gcc-4_1-branch/libjava/testsuite/libjava.jni/pr18278.java branches/gcc-4_1-branch/libjava/testsuite/libjava.jni/pr18278.out Modified: branches/gcc-4_1-branch/gcc/java/ChangeLog branches/gcc-4_1-branch/gcc/java/decl.c branches/gcc-4_1-branch/gcc/java/expr.c branches/gcc-4_1-branch/gcc/java/java-tree.h branches/gcc-4_1-branch/libjava/ChangeLog branches/gcc-4_1-branch/libjava/include/jvm.h branches/gcc-4_1-branch/libjava/jni.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18278
[Bug c++/24173] [4.0/4.1/4.2 regression] ICE with garbage collection
--- Comment #5 from reichelt at gcc dot gnu dot org 2005-11-29 19:03
---
Confirmed.
Here's a reduced testcase.
Compile with "g++ --param ggc-min-expand=0 --param ggc-min-heapsize=0".
template struct Dummy;
void dummy();
namespace std
{
template struct A;
template struct B;
template struct E {};
template struct F;
template > struct F : virtual E
{
template friend F& operator<< (F&, const char*);
};
template struct G;
template , typename = A >
struct G : F {};
typedef F F1;
typedef G G1;
}
namespace N
{
template struct X;
template struct Y {};
typedef X X1;
typedef X X2;
std::F1& operator<< (std::F1&, const X1&);
std::F1& operator<< (std::F1&, const X2&);
template struct X
{
static Y foo();
friend std::F1& operator<< (std::F1&, const X1&);
friend std::F1& operator<< (std::F1&, const X2&);
};
template Y X::foo()
{
std::G1 g;
g <<
"012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789";
}
}
It's a garbage collection related problem.
Took ages to cut that one down.
On i686-pc-linux-gnu and x86_64-unknown-linux-gnu the testcase crashes
the 4.1 branch and mainline (but not 4.0.x).
If I add "-m32" on x86_64-unknown-linux-gnu, the testcase crashes
4.0.x and mainline (but not the 4.1 branch).
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||GC, ice-on-valid-code,
||monitored
Last reconfirmed|-00-00 00:00:00 |2005-11-29 19:03:48
date||
Summary|ICE on returning a variable |[4.0/4.1/4.2 regression] ICE
|in a static templated member|with garbage collection
|function|
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24173
[Bug target/25160] New: ICE in print_operand if using -mfloat-gprs w/ non-854x -mcpu option
void foo(double a) {}
[EMAIL PROTECTED]:~$
/archive/bt/crosstool/powerpc-linux-gnuspe/head-glibc-2.3.3/bin/powerpc-linux-gnuspe-gcc
-mfloat-gprs=double -mcpu=common ~/t.c
/home/ryan/t.c: In function 'foo':
/home/ryan/t.c:1: internal compiler error: in print_operand, at
config/rs6000/rs6000.c:10674
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
[EMAIL PROTECTED]:~$
/archive/bt/crosstool/powerpc-linux-gnuspe/head-glibc-2.3.3/bin/powerpc-linux-gnuspe-gcc
-v
Using built-in specs.
Target: powerpc-linux-gnuspe
Configured with:
/archive/bt/ryan/crosstool-0.28-rc37/build/powerpc-linux-gnuspe/head-glibc-2.3.3/head/configure
--target=powerpc-linux-gnuspe --host=i686-host_pc-linux-gnu
--prefix=/archive/bt/crosstool/powerpc-linux-gnuspe/head-glibc-2.3.3
--with-local-prefix=/archive/bt/crosstool/powerpc-linux-gnuspe/head-glibc-2.3.3/powerpc-linux-gnuspe
--disable-multilib --with-newlib --without-headers --disable-nls
--enable-threads=no --enable-symvers=gnu --enable-__cxa_atexit
--enable-languages=c --disable-shared
Thread model: single
gcc version 4.2.0 20051129 (experimental)
According to the documentation, -mfloat-gprs is only available on the
MPC8540/MPC8548. So should there be a check like the following?
Index: rs6000.c
===
--- rs6000.c(revision 107671)
+++ rs6000.c(working copy)
@@ -1789,6 +1789,8 @@
case OPT_mfloat_gprs_:
rs6000_explicit_options.float_gprs = true;
+ if (rs6000_cpu != PROCESSOR_PPC8540)
+ error ("unsupported architecture for -mfloat-gprs");
if (! strcmp (arg, "yes") || ! strcmp (arg, "single"))
rs6000_float_gprs = 1;
else if (! strcmp (arg, "double"))
Also, I have another test case which may* cause an ICE in extract_insn, at
recog.c when using -mfloat-gprs=double and -mcpu=common. Since they are caused
by the same invalid combination of switches, should I open a PR for it or will
this one suffice?
*I found the ICE on the e500 branch. The test case is in C++ so I haven't have
time to build powerpc-linux-gnuspe-g++ from the head yet.
--
Summary: ICE in print_operand if using -mfloat-gprs w/ non-854x
-mcpu option
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmansfield at qnx dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-host_pc-linux-gnu
GCC target triplet: powerpc-linux-gnuspe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25160
[Bug libfortran/25116] namelist read from non-opened file
--- Comment #9 from toon at moene dot indiv dot nluug dot nl 2005-11-29 19:20 --- FX, Your patch solved the problem for me. AFAICS, this patch is indeed the correct fix for this problem. Please apply it to (at least) 4.1 and trunk. It might be appropriate for the 4.0 branch, too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25116
[Bug c++/20207] null constructor not needed in multiple inheritance
--- Comment #5 from reichelt at gcc dot gnu dot org 2005-11-29 20:33
---
This is not a bug in GCC. The code is invalid.
Let's consider the following simplified example which is just a
part of the diamond:
A0
|
A
/
B
==
struct A0
{
A0(int);
};
struct A : virtual A0
{
A() : A0(0) {}
};
struct B : virtual A
{
B() : A() {}
};
==
[12.6.2]/6 of the standard states:
All sub-objects representing virtual base classes are initialized
by the constructor of the most derived class. If the constructor
of the most derived class does not specify a mem-initializer for a
virtual base class V, then V's default constructor is called to
initialize the virtual base class subobject. If V does not have an
accessible default constructor, the initialization is ill-formed.
A mem-initializer naming a virtual base class shall be ignored
during execution of the constructor of any class that is not the
most derived class.
The first sentence means that A *and* A0 are initialized by the
constructor of B. The second sentence says that V (which is A0 in
our case) is default constructed since B's constructor does not
specify a mem-initializer for V==A0. The next sentence says that
the example is ill-formed since V==A0 does not have an accessible
default constructor. That's why g++ gives the following diagnostic:
bug.cc: In constructor 'B::B()':
bug.cc:13: error: no matching function for call to 'A0::A0()'
bug.cc:3: note: candidates are: A0::A0(int)
bug.cc:2: note: A0::A0(const A0&)
The last sentence says that A0(0) is ignored in the constructor
of A when called by B (which makes sense, since A0 should be
constructed directly by B's constructor).
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20207
[Bug c/25161] New: Internal compiler error (segfault) instead of error message
GCC version : 4.0.2 Complete C file : int a; char buf[(int)&a]; command line : gcc-4.0 -c file.c Error message : t.c:3: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see . This (Faulty) code gives normal errors with gcc-2.95 and gcc-3.2.3 -- Summary: Internal compiler error (segfault) instead of error message Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gccbug at zevv dot nl GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25161
[Bug c++/25156] [3.4/4.0/4.1 Regression] wrong error message (int instead of bool)
--- Comment #5 from gdr at gcc dot gnu dot org 2005-11-29 20:37 --- (In reply to comment #4) > | instead of the FUNCTION_TYPE's type which has the correct type, I might fix > | this later tonight. > > Try this this patch is incomplete. -- gdr at gcc dot gnu dot org changed: What|Removed |Added CC||gdr at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25156
[Bug other/25157] [4.2 Regression] /libdecnumber/decContext.h:43:49: stdint.h: No such file or directory
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-29 20:41 --- The patch here: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg02046.html Should fix it (but I have no warranties). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bje at gcc dot gnu dot org Keywords||build Summary|/libdecnumber/decContext.h:4|[4.2 Regression] |3:49: stdint.h: No such file|/libdecnumber/decContext.h:4 |or directory|3:49: stdint.h: No such file ||or directory Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25157
[Bug libstdc++/25025] Failure to build, :1:2: error: missing '(' after predicate
--- Comment #4 from pda at freeshell dot org 2005-11-29 20:41 ---
Subject: Re: Failure to build, :1:2: error: missing '(' after
predicate
On Sun, Nov 27, 2005 at 06:57:05PM -, danglin at gcc dot gnu dot org wrote:
> The "-Aa" option is likely the problem. It's probably set in
> CFLAGS. If you're using the HP tools, put the "-Aa" in your CC
> define. There's more info in the manual on this.
No, I never put "-Aa" in CFLAGS, it's being added inside the gcc build
itself. I tried your suggestion of adding "-Aa" to CC, but my build
fails much earlier in that case, due to not finding a definition of
"struct stat". Do you care to know more about that?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25025
[Bug middle-end/25158] FAIL: gcc.c-torture/execute/builtins/fprintf.c compilation
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-29 20:44 --- I would assume this was caused by the patch which fixed PR 25022. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ghazi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25158
[Bug other/25157] [4.2 Regression] /libdecnumber/decContext.h:43:49: stdint.h: No such file or directory
--- Comment #2 from andreast at gcc dot gnu dot org 2005-11-29 20:45 --- Compilation succeeded on sparc-solaris8 this morning, just after bje ci'ed I had to use the same patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25157
[Bug libgomp/25162] New: Issue with OpenMP COPYIN and gfortran
export OMP_NUM_THREADS=2 gfortran-gomp -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gomp --program-suffix=-gomp --enable-threads=posix --enable-languages=c,c++,fortran Thread model: posix gcc version 4.2.0-gomp-20050608-branch 20051126 (experimental) (merged 20051124) It seems as if the COPYIN statement is never executed in this test-program. PROGRAM TEST4 C CALL TEST1 C CALL TEST2 C END C SUBROUTINE TEST1 C DOUBLE PRECISION BPRIM COMMON /TESTCOM/ BPRIM(100) C$OMP THREADPRIVATE(/TESTCOM/) C INTEGER I C DO I = 1, 100 BPRIM( I ) = DBLE( I ) END DO C RETURN END C SUBROUTINE TEST2 C DOUBLE PRECISION BPRIM COMMON /TESTCOM/ BPRIM(100) C$OMP THREADPRIVATE(/TESTCOM/) C INTEGER I, IDUM(50) C DO I = 1, 50 IDUM(I) = I END DO C C$OMP PARALLEL COPYIN(/TESTCOM/) C CALL TEST3 C$OMP END PARALLEL C RETURN END C SUBROUTINE TEST3 C DOUBLE PRECISION BPRIM COMMON /TESTCOM/ BPRIM(100) C$OMP THREADPRIVATE(/TESTCOM/) C INTEGER K C DO K = 1, 10 PRINT *,K,BPRIM(K) END DO C RETURN END Running it produces the following results: 1 0.00 2 0.00 3 0.00 4 0.00 5 0.00 6 0.00 7 0.00 8 0.00 9 0.00 10 0.00 1 1.00 2 2.00 3 3.00 4 4.00 5 5.00 6 6.00 7 7.00 8 8.00 9 9.00 10 10.0 Running it on Intel FORTRAN 9 produces more expected results: 1 1.00 2 2.00 3 3.00 4 4.00 5 5.00 6 6.00 7 7.00 8 8.00 9 9.00 10 10.0 1 1.00 2 2.00 3 3.00 4 4.00 5 5.00 6 6.00 7 7.00 8 8.00 9 9.00 10 10.0 -- Summary: Issue with OpenMP COPYIN and gfortran Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: magnus_os at yahoo dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25162
[Bug c++/25163] New: [3.4 Regression] g++.dg/abi/vtt1.C failure with "-funit-at-a-time"
The test g++.dg/abi/vtt1.C is failing with "-funit-at-a-time" (or optimization "-O" or higher since this enables "-funit-at-a-time" by default). GCC 4.x.y doesn't seem to be affected. Since this behaviour can be triggered with just "-O2" I rate this as a regression (although "-funit-at-a-time" was introduced in 3.4.0). Gaby, do you think that this is a showstopper for 3.4.5 or not? -- Summary: [3.4 Regression] g++.dg/abi/vtt1.C failure with "-funit- at-a-time" Product: gcc Version: 3.4.5 Status: UNCONFIRMED Keywords: ABI Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25163
[Bug c++/25163] [3.4 Regression] g++.dg/abi/vtt1.C failure with "-funit-at-a-time"
--- Comment #1 from reichelt at gcc dot gnu dot org 2005-11-29 20:53 --- > The test g++.dg/abi/vtt1.C is failing with "-funit-at-a-time" > (or optimization "-O" or higher since this enables "-funit-at-a-time" Sorry, this should read "-O2" instead of just "-O". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25163
[Bug c/25161] [4.0/4.1/4.2 Regression] Internal compiler error (segfault) instead of error message
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-29 20:57 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i486-linux-gnu | GCC host triplet|i486-linux-gnu | GCC target triplet|i486-linux-gnu | Keywords||ice-on-invalid-code Known to fail|4.0.2 |4.0.2 4.1.0 4.2.0 Known to work|2.95 3.2.3 |2.95 3.2.3 3.4.0 Last reconfirmed|-00-00 00:00:00 |2005-11-29 20:57:05 date|| Summary|Internal compiler error |[4.0/4.1/4.2 Regression] |(segfault) instead of error |Internal compiler error |message |(segfault) instead of error ||message Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25161
[Bug libstdc++/25025] Failure to build, :1:2: error: missing '(' after predicate
--- Comment #5 from pda at freeshell dot org 2005-11-29 21:03 ---
Subject: Re: Failure to build, :1:2: error: missing '(' after
predicate
On Fri, Nov 25, 2005 at 08:27:34PM -, pinskia at gcc dot gnu dot org wrote:
> How did you configure GCC?
> >From using google it sounds like you configured GCC to use the GNU binutils
> >but
> it is using the native toolchain instead.
Not intentionally, but only a careful reading of the documentation
reveals to me that PATH is used (non-intuitively in my view) for as
and ld even when --with-gnu-as and --with-gnu-ld are given.
Using GNU as and --with-ld=/usr/ccs/bin/ld does indeed give me the
same error, but forcing GNU ld stops the build even sooner with:
...
checking for g++ that supports -ffunction-sections -fdata-sections... yes
checking for sin in -lm... configure: error: Link tests are not
allowed after GCC_NO_EXECUTABLES.
gmake: *** [configure-target-libstdc++-v3] Error 1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25025
[Bug java/18278] JNI functions cannot return a weak reference
--- Comment #10 from tromey at gcc dot gnu dot org 2005-11-29 21:14 --- Fix checked in. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18278
[Bug middle-end/25158] FAIL: gcc.c-torture/execute/builtins/fprintf.c compilation
--- Comment #2 from ghazi at gcc dot gnu dot org 2005-11-29 21:46 --- Hmm this is convoluted, but I think I know what's going on: We're running the builtin fprintf check. I recently added a small sanity check to ensure that fprintf_unlocked also works. Now we're getting an unresolved symbol calling fputs_unlocked. But to ensure that these _unlocked style calls don't result in unresolved symbols I had only added cases that should have been completely optimized away. E.g. fprintf_unlocked(stream, "") which should become nothing. Now hpux defines DONT_HAVE_FPUTC_UNLOCKED, notice that's fputC_unlocked not fputS_unlocked which is the unresolved symbol we get. But we have this code at the top of fold_builtin_fputs: /* If the return value is used, or the replacement _DECL isn't initialized, don't do the transformation. */ if (!ignore || !fn_fputc || !fn_fwrite) return 0; So the solution is to split these checks and move the !fn_fputc || !fn_fwrite check later on where we actually attempt to use them. That way the path which eliminates zero-length strings will still be executed. I'll put together a patch. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ghazi at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-29 21:46:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25158
[Bug libstdc++/25025] Failure to build, :1:2: error: missing '(' after predicate
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-29
22:00 ---
Subject: Re: Failure to build, :1:2: error: missing '(' after
predicate
> On Sun, Nov 27, 2005 at 06:57:05PM -, danglin at gcc dot gnu dot org
> wrote:
> > The "-Aa" option is likely the problem. It's probably set in
> > CFLAGS. If you're using the HP tools, put the "-Aa" in your CC
> > define. There's more info in the manual on this.
>
> No, I never put "-Aa" in CFLAGS, it's being added inside the gcc build
> itself. I tried your suggestion of adding "-Aa" to CC, but my build
> fails much earlier in that case, due to not finding a definition of
> "struct stat". Do you care to know more about that?
Ok, this is comming from the configure test "checking for $CC option to
accept ANSI C". This option shouldn't be used for the libstdc++ build
but obviously it is...
In order to build GCC 3.4 and later, you need an ANSI compiler. You
also need to include the full HP-UX namespace The "struct stat" error
probably is a result of not providing the appropriate namespace defines
in you CC define. -Aa provides strict ANSI. For example, these are
the defines that I use for GCC builds prior to 4.0 under HP-UX 11.11:
-D_HPUX_SOURCE -D_XOPEN_UNIX -D_XOPEN_SOURCE_EXTENDED
-D_INCLUDE__STDC_A1_SOURCE -D_INCLUDE_XOPEN_SOURCE_500
-D_HPUX_SOURCE is the important define. The others are needed for C++
library support (wide characters, etc).
Instead of trying to build C++ starting with an HP compiler, it's easier
to just build C and then use this compiler to rebuild GCC with the additional
languages that you want. It's always been tricky to bootstrap GCC using
an HP compiler and its not tested much. You should use binutils (current
CVS version is needed with GCC 4.1 and later for EH exception support).
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25025
[Bug java/24698] [4.1/4.2 regression] Failure locating .properties files inside jars
--- Comment #6 from tromey at gcc dot gnu dot org 2005-11-29 22:37 --- I tried the included test case with current svn head. I had to add '.' to classpath, then it worked for me: opsy. CLASSPATH=test.jar:. gij test1 Microsoft is crap Compiling as in comment #4 also worked fine. I also tried with the 4.1 branch (updated and built today) and this also worked fine. Not sure what to do next ... does it still fail for you? If you add . to CLASSPATH, does it work? If that works then perhaps the crash is EH related, as I see an exception if I leave out '.'. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698
[Bug c++/24173] [4.0/4.1/4.2 regression] ICE with garbage collection
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-29 23:08 ---
Shorter testcase:
template struct F;
template F &operator<<(F&, const char*);
template
struct F
{
friend F& operator<< <>(F&, const char*);
};
typedef F F1;
template struct X;
typedef X X2;
F1& operator<< (F1&, const X2&);
template struct X
{
static void foo();
friend F1& operator<< (F1&, const X2&);
};
templatevoid X::foo()
{
F1 g;
g <<"";
}
-
Commenting out the following ggc_free:
/* The NEWDECL will no longer be needed. Because every out-of-class
declaration of a member results in a call to duplicate_decls,
freeing these nodes represents in a significant savings. */
ggc_free (newdecl);
makes the testcase to work.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||mmitchel at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24173
[Bug c++/25163] [3.4 Regression] g++.dg/abi/vtt1.C failure with "-funit-at-a-time"
--- Comment #2 from gdr at integrable-solutions dot net 2005-11-29 23:20 --- Subject: Re: New: [3.4 Regression] g++.dg/abi/vtt1.C failure with "-funit-at-a-time" "reichelt at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | The test g++.dg/abi/vtt1.C is failing with "-funit-at-a-time" | (or optimization "-O" or higher since this enables "-funit-at-a-time" | by default). | | GCC 4.x.y doesn't seem to be affected. | Since this behaviour can be triggered with just "-O2" I rate this as | a regression (although "-funit-at-a-time" was introduced in 3.4.0). | | Gaby, do you think that this is a showstopper for 3.4.5 or not? I think we shoulkd deal with that after 3.4.5; but I don't consider it a showstopper. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25163
[Bug preprocessor/15772] "Permission denied" compiling glibc 2.3.3 on reiser4: EACCES fatal to #include
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-29 23:23 --- (In reply to comment #1) > This is a duplicate of 11242 which was (incorrectly) closed. > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11242 That is because it was not reported against mingw32 but a GNU/Linux OS. Anyways the mingw32 issue is a different problem and should get its own bug. The reiser4 issue is not a GCC bug but rather a bug in how things are being returned from either the kernel (reiser4's module) or glibc. And don't say it should not return NOTDIR because that really does not make sense. I should note that even HFS+ does the correct thing for access failures when accessing named forks. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15772
[Bug target/25166] New: FAIL: gcc.c-torture/execute/conversion.c compilation
Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/xgcc -B/mnt/gnu/gcc-3.3/objdir/gc c/ /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/conversion.c -w -O 0 -fno-show-column -lm -o /mnt/gnu/gcc-3.3/objdir/gcc/testsuite/conversion.x 0(timeout = 300) /usr/bin/ld: Unsatisfied symbols: __floatunsitf (first referenced in /var/tmp//ccCj8jFh.o) (code) collect2: ld returned 1 exit status compiler exited with status 1 output is: /usr/bin/ld: Unsatisfied symbols: __floatunsitf (first referenced in /var/tmp//ccCj8jFh.o) (code) collect2: ld returned 1 exit status FAIL: gcc.c-torture/execute/conversion.c compilation, -O0 -- Summary: FAIL: gcc.c-torture/execute/conversion.c compilation Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin 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=25166
[Bug preprocessor/15772] Preprocessing fails if an inaccessible directory is on include path
--- Comment #11 from ed at catmur dot co dot uk 2005-11-29 23:55 --- This is not invalid. Yes, reiser4 is broken, but so is gcc. gcc (3.4.4, I haven't used 4.x yet) dies when it encounters an inaccessible directory as a subdirectory of a member of the include path. See comment 6. -- ed at catmur dot co dot uk changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Known to fail||3.4.4 Resolution|INVALID | Summary|"Permission denied" |Preprocessing fails if an |compiling glibc 2.3.3 on|inaccessible directory is on |reiser4: EACCES fatal to|include path |#include| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15772
[Bug middle-end/24827] FAIL: gcc.dg/attr-weakref-1.c
--- Comment #7 from danglin at gcc dot gnu dot org 2005-11-29 23:55 --- The same errors occur on hppa2.0w-hp-hpux11.11 except that ld also dumps core: collect2: ld terminated with signal 10 [Bus error], core dumped /usr/bin/ld: Unsatisfied symbols: wf1 (first referenced in /var/tmp//ccuQuqgk.o) (data) wf6 (first referenced in /var/tmp//ccuQuqgk.o) (data) wf9 (first referenced in /var/tmp//ccuQuqgk.o) (data) wf10 (first referenced in /var/tmp//ccuQuqgk.o) (data) wf11 (first referenced in /var/tmp//ccuQuqgk.o) (data) wf12 (first referenced in /var/tmp//ccuQuqgk.o) (code) wf13 (first referenced in /var/tmp//ccuQuqgk.o) (code) wf14 (first referenced in /var/tmp//ccuQuqgk.o) (data) wv1 (first referenced in /var/tmp//ccuQuqgk.o) (data) wv6 (first referenced in /var/tmp//ccuQuqgk.o) (data) wv9 (first referenced in /var/tmp//ccuQuqgk.o) (data) wv10 (first referenced in /var/tmp//ccuQuqgk.o) (data) wv11 (first referenced in /var/tmp//ccuQuqgk.o) (data) wv12 (first referenced in /var/tmp//ccuQuqgk.o) (data) wv13 (first referenced in /var/tmp//ccuQuqgk.o) (data) wv14 (first referenced in /var/tmp//ccuQuqgk.o) (data) FAIL: gcc.dg/attr-weakref-1.c (test for excess errors) -- danglin at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|hppa64-hp-hpux11.11 |hppa*-*-hpux11.11 GCC host triplet|hppa64-hp-hpux11.11 |hppa*-*-hpux11.11 GCC target triplet|hppa64-hp-hpux11.11 |hppa*-*-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24827
[Bug target/25166] FAIL: gcc.c-torture/execute/conversion.c compilation
--- Comment #1 from danglin at gcc dot gnu dot org 2005-11-29 23:58 --- The same error also causes the failure of gcc.dg/torture/fp-int-convert-long-double.c: Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/xgcc -B/mnt/gnu/gcc-3.3/objdir/gc c/ /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/torture/fp-int-convert-long-double. c -O0 -fno-show-column -lm -o ./fp-int-convert-long-double.exe (timeou t = 300) /usr/bin/ld: Unsatisfied symbols: __floatunsitf (first referenced in /var/tmp//ccztHixV.o) (code) collect2: ld returned 1 exit status compiler exited with status 1 output is: /usr/bin/ld: Unsatisfied symbols: __floatunsitf (first referenced in /var/tmp//ccztHixV.o) (code) collect2: ld returned 1 exit status FAIL: gcc.dg/torture/fp-int-convert-long-double.c -O0 (test for excess errors) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25166
[Bug target/25166] FAIL: gcc.c-torture/execute/conversion.c compilation
--- Comment #2 from danglin at gcc dot gnu dot org 2005-11-30 00:00 --- And gcc.dg/torture/fp-int-convert-timode.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25166
[Bug target/25166] [4.2 Regression] FAIL: gcc.c-torture/execute/conversion.c compilation
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-30 00:00 --- This is a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|FAIL: gcc.c-|[4.2 Regression] FAIL: |torture/execute/conversion.c|gcc.c- |compilation |torture/execute/conversion.c ||compilation Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25166
[Bug testsuite/25167] New: FAIL: gcc.dg/weak/weak-14.c
Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/xgcc -B/mnt/gnu/gcc-3.3/objdir/gc c/ /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/weak/weak-14.c -O2 -fno-common -f no-show-column -lm -o ./weak-14.exe(timeout = 300) /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/weak/weak-14.c:20: error: alias defini tions not supported in this configuration /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/weak/weak-14.c:24: error: alias defini tions not supported in this configuration compiler exited with status 1 output is: /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/weak/weak-14.c:20: error: alias defini tions not supported in this configuration /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/weak/weak-14.c:24: error: alias defini tions not supported in this configuration FAIL: gcc.dg/weak/weak-14.c (test for excess errors) This test should check whether the target supports alias definitions. After some recent work on GAS, I believe that it's possible to support alias definitions when using GAS. However, the HP linker will never allow undefined symbols in final links. -- Summary: FAIL: gcc.dg/weak/weak-14.c Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin 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=25167
[Bug target/25168] New: FAIL: g++.old-deja/g++.abi/cxa_vec.C execution test
Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/testsuite/../g++ -B/mnt/gnu/gcc-3 .3/objdir/gcc/testsuite/../ /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/g++.old-deja/g++. abi/cxa_vec.C -nostdinc++ -I/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/libst dc++-v3/include/hppa2.0w-hp-hpux11.11 -I/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux 11.11/libstdc++-v3/include -I/mnt/gnu/gcc-3.3/gcc/libstdc++-v3/libsupc++ -I/mnt/ gnu/gcc-3.3/gcc/libstdc++-v3/include/backward -I/mnt/gnu/gcc-3.3/gcc/libstdc++-v 3/testsuite -fmessage-length=0 -ansi -pedantic-errors -Wno-long-long -L/mnt /gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs -L/mnt/gnu/g cc-3.3/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs -L/mnt/gnu/gcc-3.3/ objdir/hppa2.0w-hp-hpux11.11/./libiberty -lm -o ./cxa_vec.exe(timeout = 3 00) PASS: g++.old-deja/g++.abi/cxa_vec.C (test for excess errors) Setting LD_LIBRARY_PATH to .:/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/./lib stdc++-v3/src/.libs:/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3 /src/.libs:/mnt/gnu/gcc-3.3/objdir/gcc:.:/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpu x11.11/./libstdc++-v3/src/.libs:/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/./ libstdc++-v3/src/.libs:/mnt/gnu/gcc-3.3/objdir/gcc test 1 failed 3 test 2 failed 3 test 4 failed 3 FAIL: g++.old-deja/g++.abi/cxa_vec.C execution test This test fails with the new dwarf eh support. It shouldn't fail with sjlj exceptions. I've looked at the failure in some detail. The problem is this test overloads new. By somewhat unlucky circumstances, get_file_function_name_long chooses the same symbol name for the fde in the cxa_vec and an object in libstdc++.sl. This breaks the fde search for libstdc++. collect2_eh_frame_section calls get_file_function_name with kind, 'F'. This isn't documented as one on the types for get_file_function_name. Anyway, I don't think the first_global_object_name is suitable for this type. -- Summary: FAIL: g++.old-deja/g++.abi/cxa_vec.C execution test Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa*-hp-hpux* (32-bit) GCC host triplet: hppa*-hp-hpux* (32-bit) GCC target triplet: hppa*-hp-hpux* (32-bit) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25168
[Bug testsuite/25167] FAIL: gcc.dg/weak/weak-14.c
--- Comment #1 from joseph at codesourcery dot com 2005-11-30 00:34 --- Subject: Re: New: FAIL: gcc.dg/weak/weak-14.c Isn't this just bug 24478? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25167
[Bug target/25166] [4.2 Regression] FAIL: gcc.c-torture/execute/conversion.c compilation
--- Comment #4 from joseph at codesourcery dot com 2005-11-30 00:35 --- Subject: Re: New: FAIL: gcc.c-torture/execute/conversion.c compilation As explained in bug 24998, I can't test on PA at present but the fix is probably similar to that for IA64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25166
[Bug c/25169] New: [4.0 regression] tree checking failures in gcc.dg/20040203-1.c, cast-1.c, cast-2.c, cast-3.c
On i686-unknown-linux-gnu with the 4.0.x branch, I'm getting tree checking failures in gcc.dg/20040203-1.c, cast-1.c, cast-2.c, cast-3.c. From the logfile, the errors in 20040203-1.c are of this form: 20040203-1.c:17: internal compiler error: tree check: expected class 'constant', have 'unary' (nop_expr) in build_c_cast, at c-typeck.c:3330 The errors from cast-*.c are of this form: cast-1.c:25: internal compiler error: tree check: expected class 'constant', have 'declaration' (var_decl) in build_c_cast, at c-typeck.c:3330 It was clean as of here: http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00301.html It started happening here: http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg00360.html To reproduce, configure with --enable-checking=yes,rtl then bootstrap the 4.0 branch and run the testsuite. The 4.1 branch and mainline are all clean for some reason. -- Summary: [4.0 regression] tree checking failures in gcc.dg/20040203-1.c, cast-1.c, cast-2.c, cast-3.c Product: gcc Version: 4.0.3 Status: UNCONFIRMED Keywords: ice-checking Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25169
[Bug c/25169] [4.0 regression] tree checking failures in gcc.dg/20040203-1.c, cast-1.c, cast-2.c, cast-3.c
--- Comment #1 from ghazi at gcc dot gnu dot org 2005-11-30 00:44 --- Based on the date it started failing, I'm guessing it was this patch that triggered it: 2005-11-07 Paolo Bonzini <[EMAIL PROTECTED]> PR c/24599 * c-typeck.c (build_c_cast): Try using a shared constant, and see if TREE_OVERFLOW or TREE_CONSTANT_OVERFLOW really changed. (readonly_error): Fix formatting error. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25169
[Bug middle-end/25140] aliases, including weakref, break alias analysis
--- Comment #5 from geoffk at geoffk dot org 2005-11-30 01:01 --- Subject: Re: aliases, including weakref, break alias analysis On 29/11/2005, at 5:55 AM, aoliva at gcc dot gnu dot org wrote: > Make it a weak alias, then. A weak alias is still an alias and still not supported by Mach-O. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25140
[Bug c/25170] New: Erroneous error message for simple macro
Here is the test code:
typedef struct
{
int ele;
} tstruct;
#define TST(r,t) r##t = 1
void test()
{
tstruct ts;
TST(ts,.ele);
}
It generates the error:
"error: pasting "ts" and "." does not give a valid preprocessing token"
In previous versions of compiler (eg gcc-3.2.2) this generated a warning and
could therefore be ignored as another piece of unhelpful compiler output. But
now it is a error (but it isn't!) which stops compilation.
--
Summary: Erroneous error message for simple macro
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jw203198 at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25170
[Bug fortran/25171] New: FAIL: gfortran.dg/mixed_io_1.f90
Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/testsuite/../gfortran -B/mnt/gnu/ gcc-3.3/objdir/gcc/testsuite/../ /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gfortran.dg/ mixed_io_1.f90 -O0 -pedantic-errors /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gfor tran.dg/mixed_io_1.c -L/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/./libgfort ran/.libs -L/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs -L /mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/./libiberty -lm -o ./mixed_io_1 .exe(timeout = 300) In file included from /mnt/gnu/gcc-3.3/objdir/gcc/include/stdio.h:47, from /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gfortran.dg/mixed_io_1. c:1: /usr/include/sys/_mbstate_t.h:7: error: type of bit-field '__parse_size' is a GC C extension /usr/include/sys/_mbstate_t.h:8: error: type of bit-field '__dummy' is a GCC ext ension /usr/include/sys/_mbstate_t.h:9: error: type of bit-field '__shift_state' is a G CC extension compiler exited with status 1 -- Summary: FAIL: gfortran.dg/mixed_io_1.f90 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin 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=25171
[Bug fortran/25172] New: FAIL: gfortran.dg/module_equivalence_1.f90
Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/testsuite/../gfortran -B/mnt/gnu/ gcc-3.3/objdir/gcc/testsuite/../ /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gfortran.dg/ module_equivalence_1.f90 -O0 -pedantic-errors -L/mnt/gnu/gcc-3.3/objdir/hpp a2.0w-hp-hpux11.11/./libgfortran/.libs -L/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpu x11.11/./libgfortran/.libs -L/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/./lib iberty -lm -o ./module_equivalence_1.exe(timeout = 300) /var/tmp//ccoBhT9p.s: Assembler messages: /var/tmp//ccoBhT9p.s:204: Error: symbol `test_equiv.eq.1_' is already defined as "*COM*"/16 /var/tmp//ccoBhT9p.s:205: Error: symbol `test_equiv.eq.1_' is already defined as "*COM*"/16 compiler exited with status 1 Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/testsuite/../gfortran -B/mnt/gnu/ gcc-3.3/objdir/gcc/testsuite/../ /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gfortran.dg/ module_equivalence_1.f90 -O0 -pedantic-errors -L/mnt/gnu/gcc-3.3/objdir/hpp a2.0w-hp-hpux11.11/./libgfortran/.libs -L/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpu x11.11/./libgfortran/.libs -L/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/./lib iberty -lm -o ./module_equivalence_1.exe(timeout = 300) /var/tmp//ccoBhT9p.s: Assembler messages: /var/tmp//ccoBhT9p.s:204: Error: symbol `test_equiv.eq.1_' is already defined as "*COM*"/16 /var/tmp//ccoBhT9p.s:205: Error: symbol `test_equiv.eq.1_' is already defined as "*COM*"/16 compiler exited with status 1 -- Summary: FAIL: gfortran.dg/module_equivalence_1.f90 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin 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=25172
[Bug c/25173] New: gcc outputs unnecessary warnings
I refer to the very frequent warnings about signed/unsigned mismatches. Can I please say this: What does it matter if the signedness of pointers don't match? Surely it only *really* matters when a pointer is actually dereferenced. That is the only time when signedness really matters. The rest of the time you should be able to switch between signed/unsigned to your heart's content because it doesn't have any effect. Why should a compiler generate warning messages about something that is quite irrelevant? It is only when you actually use a signed/unsigned pointer that the signedness has any effect! Please exclude those warnings from the -Wall setting and only have them enabled if explicitly requested by some fastidious programmer who has pedants in his/her pants. -- Summary: gcc outputs unnecessary warnings Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jw203198 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25173
[Bug c/25170] Erroneous error message for simple macro
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-30 01:33 --- This has been an error since 3.0.x. And it is an error in your code. *** This bug has been marked as a duplicate of 7976 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25170
[Bug preprocessor/7976] pasting xxx and xxx does not give a valid preprocessing token
--- Comment #19 from pinskia at gcc dot gnu dot org 2005-11-30 01:33 --- *** Bug 25170 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jw203198 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7976
[Bug c/25173] gcc outputs unnecessary warnings
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-30 01:36 ---
Because the code is really invalid C.
that is:
int *a;
unsigned int *f(void)
{
return a;
}
Is invalid C. We used to just output a warning with -pedantic but now the
warning is always on unless you add -Wno-pointer-sign.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25173
[Bug fortran/25174] New: gfortran ignores explicit return type for functions
gfortran seems to ignore explicit return types of functions. Example follows: -bug.for PROGRAM BUG external real function Mfunc real*4 X,Y X = Xfunc() Y = Mfunc() write(6,*) X,Y stop end real function Xfunc() Xfunc = 17.232 return end real function Mfunc() Mfunc = 17.232 return end -bug.for-- When run, this gives: 17.23200 1.0995535E+09 STOP 0 Compilation was: [...]/gfortran -Wall -o bug bug.for -L[...]/lib64 \ -Wl,-rpath,[...]/lib64 (Long path names replaced with [...]). As usual, thank you very much. The gcc collection is a wonderful tool. -Mike -- Summary: gfortran ignores explicit return type for functions Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: albertm at uphs dot upenn dot edu GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25174
