[Bug c/30596] New: openssl-0.9.8d compile error
Hi, ... `-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead. evp_pkey.c: In function 'EVP_PKEY2PKCS8_broken': evp_pkey.c:382: warning: function called through a non-compatible type evp_pkey.c:382: note: if this code is reached, the program will abort evp_pkey.c: In function 'dsa_pkey2pkcs8': evp_pkey.c:478: warning: function called through a non-compatible type evp_pkey.c:478: note: if this code is reached, the program will abort evp_pkey.c: In function 'EVP_PKEY2PKCS8_broken': evp_pkey.c:416: internal compiler error: in maybe_add_or_update_back_dep_1, at sched-deps.c:245 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[2]: *** [evp_pkey.o] Error 1 make[2]: Leaving directory `/home/keti/date/2007/1/11/gnome/openssl-0.9.8d/crypto/evp' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/home/keti/date/2007/1/11/gnome/openssl-0.9.8d/crypto' make: *** [build_crypto] Error 1 > vi +416 crypto/evp/evp_pkey.c > cc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++,treelang Thread model: posix gcc version 4.2.0 20070124 (prerelease) > -- Summary: openssl-0.9.8d compile error Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: happyarch at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30596
[Bug c/30596] openssl-0.9.8d compile error
--- Comment #1 from happyarch at gmail dot com 2007-01-26 09:54 --- Created an attachment (id=12958) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12958&action=view) preprocessed sources and output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30596
[Bug libgomp/30540] Document default value of implementation-dependent OpenMP settings
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-01-26 09:58 ---
> Here, the default value is not documented; it can be found in
> "3 Environment Variables" ("If undefined, dynamic adjustment is disabled
> by default."), but this is not obvious. Especially, since the omp_get_*
> functions only link to omp_set_* and not to the OMP_* environment variables.
Agreed. Regarding this, it was almost done, but then I removed what I had.
Don't ask why ...
> And OMP_NUM_THREADS's default setting is completely undefined; does it
> use by default one or the maximal number of available processors?
Section 3.3 states:
"If undefined one thread per CPU online is used."
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-01-26 09:58:54
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30540
[Bug target/30596] openssl-0.9.8d compile error
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-01-26 10:55 --- How did you invoke gcc? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c |target GCC target triplet||i?86-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30596
[Bug libgomp/30540] Document default value of implementation-dependent OpenMP settings
--- Comment #2 from burnus at gcc dot gnu dot org 2007-01-26 11:06 --- > > And OMP_NUM_THREADS's default setting is completely undefined; does it > > use by default one or the maximal number of available processors? > > Section 3.3 states: > "If undefined one thread per CPU online is used." Missed that since the order changed from what, allowed values, default (used in the description of the other environment variables) to what, default, allowed values for OMP_NUM_THREADS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30540
[Bug libgomp/30546] [4.3 regression] build fail in libgomp because makeinfo is missing
--- Comment #2 from jakub at gcc dot gnu dot org 2007-01-26 12:34 --- The only other place that generates info files is gcc subdir and there it uses BUILD_INFO conditional, if makeinfo is not present or is too old, it simply doesn't build the documentation. Perhaps libgomp could do the same. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30546
[Bug libstdc++/28125] Cannot build cross compiler for Solaris: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #12 from bkoz at gcc dot gnu dot org 2007-01-26 12:44 --- Reopen.. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28125
[Bug other/12411] GCC depends on undefined ISO C behavior (order of execution)
--- Comment #3 from manu at gcc dot gnu dot org 2007-01-26 12:57 --- This should be warned by -Wsequence-points. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12411
[Bug tree-optimization/30334] Request for -Wundefined
--- Comment #12 from manu at gcc dot gnu dot org 2007-01-26 13:01 --- (In reply to comment #11) > Subject: Re: Request for -Wundefined > > "manu at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: > > | Not sure about this one either, there seems to be a warning in C++ > | but I am not sure what option controls it now: PR 30368. > > Some warnings will stay non-controlable. Hum, ok, I didn't notice that the request is to implement the warning in C. -- manu at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||12242, 29465, 30457 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
[Bug libgomp/30546] [4.3 regression] build fail in libgomp because makeinfo is missing
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-01-26 13:07 --- (In reply to comment #2) > The only other place that generates info files is gcc subdir and there it uses > BUILD_INFO conditional, if makeinfo is not present or is too old, it simply > doesn't build the documentation. Perhaps libgomp could do the same. Sounds a good plan. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-26 13:07:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30546
[Bug bootstrap/30589] [4.3 regression] C99 extern inline patch broke bootstrap on i386-pc-mingw32
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-01-26 13:11 --- So maybe a right fixinclude change could be to look into _mingw.h for #define __CRT_INLINE extern __inline__ and change it (for mainline) to # if __STDC_VERSION__ >= 199901L # define __CRT_INLINE extern inline __attribute__((__gnu_inline__)) # else # define __CRT_INLINE extern __inline__ # endif I don't know how fixinclude works, but that sounds like a simple and contained hack. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-26 13:11:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
[Bug target/30058] [4.3 regression] bootstrap broken on i386-unknown-netbsdelf2.0.2
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-01-26 13:16
---
Created an attachment (id=12960)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12960&action=view)
Preprocessed source for file a.c
Minimal testcase using the xgcc binary made before the bootstrap fails:
$ cat a.c
#include
int main (void)
{
return 0;
}
$ cat b.c
#include
void foo(void) { ; }
$ /home/fxcoudert/debug/ibin/./gcc/xgcc -B/home/fxcoudert/debug/ibin/./gcc/
-B/home/fxcoudert/debug/ibin/../irun/i386-unknown-netbsdelf2.0.2/bin/
-B/home/fxcoudert/debug/ibin/../irun/i386-unknown-netbsdelf2.0.2/lib/ -isystem
/home/fxcoudert/debug/ibin/../irun/i386-unknown-netbsdelf2.0.2/include -isystem
/home/fxcoudert/debug/ibin/../irun/i386-unknown-netbsdelf2.0.2/sys-include
-std=c99 a.c b.c
/var/tmp//ccbQwhuy.o(.text+0x0): In function `__sigaddset14':
: multiple definition of `__sigaddset14'
/var/tmp//ccqlPWOi.o(.text+0x0): first defined here
/var/tmp//ccbQwhuy.o(.text+0x67): In function `__sigdelset14':
: multiple definition of `__sigdelset14'
/var/tmp//ccqlPWOi.o(.text+0x67): first defined here
/var/tmp//ccbQwhuy.o(.text+0xd0): In function `__sigismember14':
: multiple definition of `__sigismember14'
/var/tmp//ccqlPWOi.o(.text+0xd0): first defined here
/var/tmp//ccbQwhuy.o(.text+0x127): In function `__sigemptyset14':
: multiple definition of `__sigemptyset14'
/var/tmp//ccqlPWOi.o(.text+0x127): first defined here
/var/tmp//ccbQwhuy.o(.text+0x158): In function `__sigfillset14':
: multiple definition of `__sigfillset14'
/var/tmp//ccqlPWOi.o(.text+0x158): first defined here
collect2: ld returned 1 exit status
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30058
[Bug target/30058] [4.3 regression] bootstrap broken on i386-unknown-netbsdelf2.0.2
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-01-26 13:17 --- Created an attachment (id=12961) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12961&action=view) Preprocessed source file for b.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30058
[Bug libstdc++/28125] Cannot build cross compiler for Solaris: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #13 from bkoz at gcc dot gnu dot org 2007-01-26 13:23 --- Revert. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28125
[Bug libgomp/30471] OpenMP with static linking fails in fortran on amd64
--- Comment #7 from jakub at gcc dot gnu dot org 2007-01-26 13:32 --- Static linking with -lpthread (which -fopenmp uses) is not supported in glibc/NPTL. You can probably make it working by adding -Wl,--whole-archive -lpthread -Wl,--no-whole-archive to the command line, but there are no guarantees it will work. Anyway, this is not a GCC bug but GLIBC feature. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30471
[Bug tree-optimization/15357] [tree-ssa] combing if statements
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-01-26 13:44 --- Another thing we should be able to do is combine bit-tests like if (a & (1 << b)) if (a & (1 << c)) ... to a single test if (a & ((1 << b) | (1 << c)) == ((1 << b) | (1 << c))) ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15357
[Bug libgomp/29987] libgomp.c++/ctor-9.C failure
--- Comment #4 from jakub at gcc dot gnu dot org 2007-01-26 13:47 ---
As a workaround, gcc could check for this in configure and if it detects the
bug,
override TARGET_ASM_SELECT_SECTION such that on Solaris with this bug
detected it would:
section *
solaris_elf_select_section (tree decl, int reloc,
unsigned HOST_WIDE_INT align)
{
#if HAVE_AS_TBSS_BUG
if (TREE_CODE (decl) == VAR_DECL && DECL_THREAD_LOCAL_P (decl)
&& categorize_decl_for_section (decl, reloc, flag_pic) == SECCAT_TBSS)
/* Solaris AS doesn't handle .tbss variables properly. Use .tdata section.
*/
return get_named_section (DECL_P (decl) ? decl : NULL, ".tdata", reloc);
#endif
return default_elf_select_section_1 (decl, reloc, align, flag_pic);
}
and similarly with TARGET_ASM_UNIQUE_SECTION.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29987
[Bug libstdc++/28125] Cannot build cross compiler for Solaris: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #14 from bkoz at gcc dot gnu dot org 2007-01-26 13:49 --- Subject: Bug 28125 Author: bkoz Date: Fri Jan 26 13:49:42 2007 New Revision: 121203 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121203 Log: 2007-01-26 Benjamin Kosnik <[EMAIL PROTECTED]> Revert. 2006-12-11 Benjamin Kosnik <[EMAIL PROTECTED]> PR libstdc++/28125 * acinclude.m4 (GLIBCXX_CHECK_ICONV_SUPPORT): Remove link test, ie AC_CHECK_LIB for libiconv. Instead, use bits of AM_ICONV. * configure: Regenerate. * scripts/testsuite_flags.in (cxxflags): Add LIBICONV bits. Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog branches/gcc-4_2-branch/libstdc++-v3/acinclude.m4 branches/gcc-4_2-branch/libstdc++-v3/configure branches/gcc-4_2-branch/libstdc++-v3/scripts/testsuite_flags.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28125
[Bug libgomp/29935] Support OpenMP Runtime API for Profiling
--- Comment #1 from jakub at gcc dot gnu dot org 2007-01-26 13:52 --- This looks as a very convoluted API, far better would be simply write special .eh_frame info for the libgomp thread body function which would point the debuggers/profilers to the stack/saved registers of the thread that assigned work to the threads. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29935
[Bug bootstrap/30598] New: Misdetection of COMDAT group support
We discovered this issue while importing newer gcc 4.1* into NetBSD tree and
saw that suddently it no longer thinks COMDAT is supported.
I've tracked it down to the following change:
http://gcc.gnu.org/viewcvs?view=rev&revision=99395
that changed configure.ac to check $ld_date to decide if COMDAT is supported.
There are two problems with that change:
1) Released versions of binutils 2.16* do NOT have date in the ld version
string:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/ldver.c?rev=1.10&content-type=text/x-cvsweb-markup&cvsroot=src
fprintf (stdout, _("GNU ld version %s\n"), BFD_VERSION_STRING);
2) The above change to confgiure unconditionally overrides
gcc_cv_as_comdat_group and gcc_cv_as_comdat_group_percent passed via
environment
so we cannot even work around the problem #1 by supplying correct values
--
Summary: Misdetection of COMDAT group support
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uwe at netbsd dot org
GCC build triplet: i386--netbsdelf
GCC host triplet: i386--netbsdelf
GCC target triplet: i386--netbsdelf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30598
[Bug bootstrap/30598] Misdetection of COMDAT group support
--- Comment #1 from uwe at netbsd dot org 2007-01-26 14:18 --- On the second thought, I might be confused here. Please, leave UNCONFIRMED. I'll do more testing and get back with an update later today. Sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30598
[Bug fortran/30594] Calling inquire (iolength) crashes with -malign-double
--- Comment #4 from schnetter at aei dot mpg dot de 2007-01-26 14:36 --- I have read the documentation, and I understand what the option does. I compile my complete programme and all its libraries with this option. It was my assumption that the compiler would create working code with and without this option, that is, that the run-time library could handle both cases. My patch would change the run-time library so that this is indeed the case for inquire(iolength). Creating a run-time library that works with -malign-double is certainly possible; the question is whether the additional work is deemed worthwhile. Looking on the web, most numerical benchmarks use -malign-double on the i386. At the same time I see many complaints from people who use this option without knowing what it does and reporting spurious errors, which is a maintenance burden. I realise that any bug report concerning -malign-double must hit a sore spot with you. If -malign-double is really unsupported, then the documentationcould be changed to include a warning sentence like: "Calling standard library routines is not supported when this option is used. Your program may segfault randomly or silently produce wrong results." As it, I honestly interpreted the documentation as saying that one is safe if (a) the whole programme is compiled with this option, and (b) no structure involved in library calls contains double, long double, or long long. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30594
[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable
--- Comment #2 from temp at pathengine dot com 2007-01-26 14:42 --- Can we do anything to work around this issue? Is there an option, for example, to turn off just named return value optimisation? (I did a quick search of the manual but couldn't find anything.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590
[Bug c/24577] diagnostic informative note labelled "error"
--- Comment #2 from manu at gcc dot gnu dot org 2007-01-26 15:34 --- So what is the correct solution? Use inform or notice? Or don't show the message as C++ does? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24577
[Bug c++/8715] '~' operator for unsigned char and conversion to bool
--- Comment #6 from manu at gcc dot gnu dot org 2007-01-26 16:00 --- OK. I see now. This seems hard to fix, since it is exposing the current implementation of a conversion to bool. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8715
[Bug c/21759] Implement warning for codes at the intersection of C and C++
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-26 16:08 --- Gabriel, if you could do a quick and dirty list of what remains to be done, perhaps some potential contributor would try to implement it as an entry point to GCC development. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21759
[Bug fortran/30594] Calling inquire (iolength) crashes with -malign-double
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-01-26 16:11 --- I understand Erik's concern. -malign-double makes a significant performance difference on some of these machines and is commonly used. The surest way to handle this is to put compute intensive code in separate files and create libraries that have no I/O involved. Then the driver routines that have the I/O can be compiled separately without any concern and link the compute routines in. I am interested to have a look at the patch Erik is proposing to see how intrusive it is. It may be suitable for '4.3 only' as an enhancement. I think we have bumped the library version already on 4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30594
[Bug target/30599] New: long double declaration rounds to double instead
Hi, Since bug 30255 has been declared as never going to be fixed, I've been enjoying going through half a million lines of code looking for places where I have to declare things long double to keep gcc from arbitrarily rounding down intermediate results. The problem now is that I have come across a case where the exact opposite occurs: If I declare a variable long double, gcc inserts a round to double before computing the square root, where it does not if I declare it double. I will upload the file seperately, but here's the section of code: for (i=0; i < N; i++) t0 += X[i]*X[i]; t0 = sqrt(t0); When compiled with t0 declared as double, no spills are performed by gcc, and 80-bit accuracy is maintained throughout the computation (critical to avoid overflow). When declared as long double, however, the following code is inserted: fstpl 16(%rsp) fldl16(%rsp) fld %st(0) fsqrt So, a long double is rounded to double by gcc, even though there is no store in the algorithm. Any idea what is going on, and is there anything to be done? I will post the short file seperately. You can gen both assemblies to see the difference with gcc -O -mfpmath=387 -S nrm2.c # gen double declaration gcc -O -mfpmath=387 -DLD_ -S nrm2.c # gen long double variant Thanks, Clint -- Summary: long double declaration rounds to double instead Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: whaley at cs dot utsa dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30599
[Bug target/30599] long double declaration rounds to double instead
--- Comment #1 from whaley at cs dot utsa dot edu 2007-01-26 16:21 --- Created an attachment (id=12963) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12963&action=view) Can be compiled to .s as described in report to duplicate error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30599
[Bug c++/8715] '~' operator for unsigned char and conversion to bool
--- Comment #7 from rearnsha at gcc dot gnu dot org 2007-01-26 16:46 --- (In reply to comment #6) > OK. I see now. This seems hard to fix, since it is exposing the current > implementation of a conversion to bool. > No, it's not the 'current implementation', its the way the C and C++ standards say this has to happen. When arithmetic operators are applied to sub-int sized operands they are first converted to int (or unsigned int if they can't be represented in int -- which is only the case when you have a machine where sizeof(unsigned short) == sizeof(unsigned int), or something similar). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8715
[Bug c++/8715] '~' operator for unsigned char and conversion to bool
--- Comment #8 from manu at gcc dot gnu dot org 2007-01-26 16:56 --- (In reply to comment #7) > (In reply to comment #6) > > OK. I see now. This seems hard to fix, since it is exposing the current > > implementation of a conversion to bool. > > > > No, it's not the 'current implementation', its the way the C and C++ standards > say this has to happen. When arithmetic operators are applied to sub-int > sized > operands they are first converted to int (or unsigned int if they can't be > represented in int -- which is only the case when you have a machine where > sizeof(unsigned short) == sizeof(unsigned int), or something similar). > I think I expressed myself badly. I meant that the warning is appropriate but the message is confusing because it is exposing that when doing bool x = ~b; we actually do bool x = (~b != 0); So an appropriate message would say something like: test.cpp:5: warning: '(bool) ~b' is always true But that is hard to achieve with the current implementation. Don't you agree? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8715
[Bug c++/8715] '~' operator for unsigned char and conversion to bool
--- Comment #9 from rearnsha at gcc dot gnu dot org 2007-01-26 17:03 --- (In reply to comment #8) > I meant that the warning is appropriate but > the message is confusing because it is exposing that when doing > > bool x = ~b; > > we actually do > > bool x = (~b != 0); > Or, more precisely, bool x = (~(int) b) != 0; > So an appropriate message would say something like: > > test.cpp:5: warning: '(bool) ~b' is always true > Don't you agree? > Yes, that would be nice, but hard to implement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8715
[Bug libgcj/30600] New: gnu.gcj.convert.BytesToCharsetAdaptor calculates bad argument for java.nio.Buffer.limit(int)
Sometimes, gnu.gcj.convert.BytesToCharsetAdaptor's read method calls inBuffer.limit(int) with a value that exceeds the buffer capacity. This can be easily reproduced when BytesToCharsetAdaptor is used with an input byte aray that does not have to be decoded from the start, but from a greater possition (inpos > 0). In this case the line inBuf.limit(inpos + inlength); leads to: java.lang.IllegalArgumentException at java.nio.Buffer.limit(libgcj.so.7) at gnu.gcj.convert.BytesToCharsetAdaptor.read(libgcj.so.7) at java.lang.String.init(libgcj.so.7) at java.lang.String.(libgcj.so.7) at BytesToCharsetAdaptorBug.main(BytesToCharsetAdaptorBug.java:6) Please see the attached example. -- Summary: gnu.gcj.convert.BytesToCharsetAdaptor calculates bad argument for java.nio.Buffer.limit(int) Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kaloian at doganov dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30600
[Bug libgcj/30600] gnu.gcj.convert.BytesToCharsetAdaptor calculates bad argument for java.nio.Buffer.limit(int)
--- Comment #1 from kaloian at doganov dot org 2007-01-26 17:15 --- Created an attachment (id=12964) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12964&action=view) Short test case that demonstrates the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30600
[Bug libgcj/30600] gnu.gcj.convert.BytesToCharsetAdaptor calculates bad argument for java.nio.Buffer.limit(int)
--- Comment #2 from kaloian at doganov dot org 2007-01-26 17:18 --- (From update of attachment 12964) The example works fine if you try to create the demo String using the whole byte array. But if you wish to skip the fist byte this leads to IllegalArgumentException because of the bad calculations in BytesToCharsetAdaptor. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30600
[Bug fortran/30481] Accepts namelist-group object with assumed character length
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-01-26 17:25 --- Subject: Bug 30481 Author: jvdelisle Date: Fri Jan 26 17:25:06 2007 New Revision: 121207 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121207 Log: 2007-01-26 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/30532 * scanner.c (load_line): Remove check fot ctrl-z and don't gobble. 2007-01-26 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30481 * match.c (gfc_match_namelist): Add check for assumed size character in namelist and provide error if found. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/match.c branches/gcc-4_2-branch/gcc/fortran/scanner.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30481
[Bug fortran/30532] ^Z as EOF?
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-01-26 17:25 --- Subject: Bug 30532 Author: jvdelisle Date: Fri Jan 26 17:25:06 2007 New Revision: 121207 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121207 Log: 2007-01-26 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/30532 * scanner.c (load_line): Remove check fot ctrl-z and don't gobble. 2007-01-26 Paul Thomas <[EMAIL PROTECTED]> PR fortran/30481 * match.c (gfc_match_namelist): Add check for assumed size character in namelist and provide error if found. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/match.c branches/gcc-4_2-branch/gcc/fortran/scanner.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30532
[Bug fortran/30481] Accepts namelist-group object with assumed character length
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-01-26 17:28 --- Subject: Bug 30481 Author: jvdelisle Date: Fri Jan 26 17:28:07 2007 New Revision: 121208 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121208 Log: 2007-01-26 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/30532 * gfortran.dg/ctrl-z.f90: New test. 2007-01-26 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/30481 * gfortran.dg/namelist_assumed_char.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/ctrl-z.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/namelist_assumed_char.f90 Modified: branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30481
[Bug fortran/30532] ^Z as EOF?
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-01-26 17:28 --- Subject: Bug 30532 Author: jvdelisle Date: Fri Jan 26 17:28:07 2007 New Revision: 121208 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121208 Log: 2007-01-26 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/30532 * gfortran.dg/ctrl-z.f90: New test. 2007-01-26 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/30481 * gfortran.dg/namelist_assumed_char.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/ctrl-z.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/namelist_assumed_char.f90 Modified: branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30532
[Bug fortran/30481] Accepts namelist-group object with assumed character length
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-01-26 17:29 --- Fised on 4.2 and 4.3 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30481
[Bug fortran/30532] ^Z as EOF?
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-01-26 17:30 --- Fixed on 4.2 and 4.3 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30532
[Bug target/30596] openssl-0.9.8d compile error
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-26 17:39 --- First off OpenSSL has undefined code in it so you should report to them, the following warnings: evp_pkey.c: In function 'EVP_PKEY2PKCS8_broken': evp_pkey.c:382: warning: function called through a non-compatible type evp_pkey.c:382: note: if this code is reached, the program will abort evp_pkey.c: In function 'dsa_pkey2pkcs8': evp_pkey.c:478: warning: function called through a non-compatible type evp_pkey.c:478: note: if this code is reached, the program will abort Secon this is a dup of bug 29841. *** This bug has been marked as a duplicate of 29841 *** -- 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=30596
[Bug rtl-optimization/29841] [4.2/4.3 regression] ICE with scheduling and __builtin_trap
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-01-26 17:39 --- *** Bug 30596 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||happyarch at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29841
[Bug fortran/30594] Calling inquire (iolength) crashes with -malign-double
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-01-26 17:43 --- (In reply to comment #4) > I have read the documentation, and I understand what the option does. I > compile my complete programme and all its libraries with this option. You did not compile libc or libm with the option or anyother system library so really you will get invalid results there. You need to compile your whole system including all of GCC's library with the option to get valid results. > I understand Erik's concern. -malign-double makes a significant performance > difference on some of these machines and is commonly used. Yes but the ABI says doubles can only be aligned word wise. I am sorry to that the ABI sucks but guess what complain to AT&T for creating a sucky ABI. And complain to Intel/AMD for not having hardware that supports loading double aligned only on the word boundry, even IBM makes those now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30594
[Bug target/30599] long double declaration rounds to double instead
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-26 17:49 --- Use sqrtl then if you don't want the rounding. -- 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=30599
[Bug libstdc++/30586] [4.2/4.3 regression] Namespace pollution in c++ headers
--- Comment #6 from paolo at gcc dot gnu dot org 2007-01-26 18:00 --- Subject: Bug 30586 Author: paolo Date: Fri Jan 26 18:00:42 2007 New Revision: 121209 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121209 Log: 2007-01-26 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/30586 * config/cpu/ia64/atomic_word.h: Just include . * testsuite/abi/30586.cc: New. Added: trunk/libstdc++-v3/testsuite/abi/30586.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/cpu/ia64/atomic_word.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30586
[Bug libstdc++/30586] [4.2/4.3 regression] Namespace pollution in c++ headers
--- Comment #7 from paolo at gcc dot gnu dot org 2007-01-26 18:03 --- Subject: Bug 30586 Author: paolo Date: Fri Jan 26 18:03:44 2007 New Revision: 121210 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121210 Log: 2007-01-26 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/30586 * config/cpu/ia64/atomic_word.h: Just include . * testsuite/abi/30586.cc: New. Added: branches/gcc-4_2-branch/libstdc++-v3/testsuite/abi/30586.cc Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog branches/gcc-4_2-branch/libstdc++-v3/config/cpu/ia64/atomic_word.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30586
[Bug target/30182] FAIL: gcc.dg/pr28796-2.c (test for excess errors)
--- Comment #3 from sje at gcc dot gnu dot org 2007-01-26 18:16 --- Subject: Bug 30182 Author: sje Date: Fri Jan 26 18:16:29 2007 New Revision: 121211 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121211 Log: PR other/30182 * config/pa/pa.h (TARGET_HPUX_11): New. * config/pa/pa-hpux11.h (TARGET_HPUX_11): New. * config/pa/pa.c (pa_init_builtins): Use TARGET_HPUX_11. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa-hpux11.h trunk/gcc/config/pa/pa.c trunk/gcc/config/pa/pa.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30182
[Bug c++/30601] New: [4.3 regression] -Wreturn-type warns about more than what the documentation says
This little code
---
const double foo() { return 1.; }
---
used to be fine in C++ even in the presence of -Wreturn-type but now
yields a warning with recent mainline:
deal.II/tests> /tmp/bangerth/bin/bin/c++ -Wreturn-type -c x.cc
x.cc:1: warning: type qualifiers ignored on function return type
The point is that in C++, this sort of code is pretty common
because the return type may be a template-type or derived through
template metaprogramming typedef tricks, unlike in C where it may
indeed be an oversight. The documentation appears to recognize this
because it says that -Wreturn-type only warns about the const
qualifier for C, not for C++. Yet, the current code does warn. I
suspect that this was introduced in the recent reorganizations of
much of the warnings.
Best
Wolfgang
--
Summary: [4.3 regression] -Wreturn-type warns about more than
what the documentation says
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30601
[Bug c++/30602] New: [4.3 regression] Error with canonical types
I get a warning about canonical types like this from one of my codes: tests/bits> /tmp/bangerth/bin/bin/g++ -DHAVE_CONFIG_H -DHAVE_ISNAN -ggdb -DDEBUG -pedantic -Wall -Wpointer-arith -Wwrite-s trings -Winline -Woverloaded-virtual -Wsynth -Wsign-compare -Wconversion -Wswitch -ftemplate-depth-128 -Wno-long-long -fPI C -I/tmp/bangerth/d/deal.II/base/include -I/tmp/bangerth/d/deal.II/lac/include -I/tmp/bangerth/d/deal.II/deal.II/include -I/tmp/bangerth/d/deal.II/contrib/boost/include -I/tmp/bangerth/d/deal.II/contrib -Wno-conversion -c step-13.cc -o step-13 /obj.g.o In file included from /tmp/bangerth/d/deal.II/contrib/boost/include/boost/type_traits.hpp:61, from /tmp/bangerth/d/deal.II/base/include/base/thread_management.h:25, from step-13.cc:29: /tmp/bangerth/d/deal.II/contrib/boost/include/boost/type_traits/extent.hpp:96: warning: canonical types differ for identic al types T [] and T [] > type_0 type_6 VOID align 8 symtab 0 alias set -1 canonical type 0xb5f8e478> > type_0 type_6 VOID align 8 symtab 0 alias set -1 canonical type 0xb5e44f70> /tmp/bangerth/d/deal.II/contrib/boost/include/boost/type_traits/extent.hpp:96: warning: canonical types differ for identic al types T [] and T [] > type_0 type_6 VOID align 8 symtab 0 alias set -1 canonical type 0xb5f8e478> > type_0 type_6 VOID align 8 symtab 0 alias set -1 canonical type 0xb5e44f70> The problem is: whenever I use -save-temps, or run everything by hand through -E and then use the same compiler with the same flags on the result, the bug goes away. So for the moment, I'm a bit unsure how exactly I can submit the code :-( Doug, is there anything that you can glean from the output above that would help in any way? -- Summary: [4.3 regression] Error with canonical types Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30602
[Bug fortran/30594] Calling inquire (iolength) crashes with -malign-double
--- Comment #7 from kargl at gcc dot gnu dot org 2007-01-26 18:52 --- (In reply to comment #4) > I have read the documentation, and I understand what the option does. I > compile my complete programme and all its libraries with this option. You did not compile all of the needed libraries with -malign-double. You'll need to recompile at least libgfortran with this option and maybe libgcc, and if you use OpenMP you may need to recompile libgomp. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30594
[Bug c++/30601] [4.3 regression] -Wreturn-type warns about more than what the documentation says
--- Comment #1 from manu at gcc dot gnu dot org 2007-01-26 18:56 --- Why am I in the CC list? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30601
[Bug c++/30603] New: wrong results - when long long varaible is multiplied with big number
I am trying to check memory limit for my application. I am multiplying some
constant with argv[1]. I am getting correct results if my arg[1] is 5000 and
incorrect value if arg[1] is 6000. Infact it is returning samller value when I
multiply with 6000.
my code is as follows:
==
#include
#include
using namespace std;
int main(int args, char **argv)
{
int rowsetSize = atoi(argv[1]);
const long long twoGB = 256000UL; //2.5 GB
const unsigned int recordLength = 30046;
long long totalMemory = (long long) ( 50L * rowsetSize * recordLength ) ;
{
cout << "total Memory: " << totalMemory << " rowset size: " << rowsetSize
<< " record length: " << recordLength << endl;
}
if ( totalMemory > twoGB )
{
cout << "program memory requirement exceeds 2.5GB, try again by
decreasing the transaction size." << endl;
}
I compiled as
gcc -lstdc++ -g -o limit1.exe limit1.cpp
output
===
$ ./limit1.exe 6000
total Memory: 423865408 rowset size: 6000 record length: 30046
$ ./limit1.exe 5000
total Memory: 3216532704 rowset size: 5000 record length: 30046
program memory requirement exceeds 2.5GB, try again by decreasing the
transaction size.
my system specification:
=
$ uname -a
Linux BMC011 2.6.9-22.0.2.ELsmp #1 SMP Thu Jan 5 17:13:01 EST 2006 i686 i686
i386 GNU/Linux
thank
nirmala
--
Summary: wrong results - when long long varaible is multiplied
with big number
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jvn245 at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30603
Re: ED7152
Good day, Viazzgra $1, 80 Ciazzlis $3, 00 Levizztra $3, 35 http://www.printeryml.*com ( Important ! Remove "*" ) -- know what it might achieve... but he now concentrated as he had never done in his life on forcing that bead of light right back into Voldemort s wand... and slowly... very slowly ...it moved along the golden thread
[Bug preprocessor/27777] Bad diagnostic emission when #error contains a trigraph
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-26 19:42 --- I am testing a patch to defer error messages in this situation. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-05-27 17:38:11 |2007-01-26 19:42:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[Bug tree-optimization/29516] gfortran miscompiled
--- Comment #37 from rakdver at gcc dot gnu dot org 2007-01-26 19:56 --- Subject: Bug 29516 Author: rakdver Date: Fri Jan 26 19:56:05 2007 New Revision: 121214 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121214 Log: PR tree-optimization/29516 * tree-ssa-address.c (tree_mem_ref_addr, add_to_parts, most_expensive_mult_to_index, addr_to_parts, create_mem_ref, maybe_fold_tmr): Make the type of fields of TARGET_MEM_REF sizetype. (move_fixed_address_to_symbol, move_pointer_to_base, aff_combination_remove_elt): New functions. * tree.def (TARGET_MEM_REF): Add comment on types of the operands. * gcc.dg/tree-ssa/loop-20.c: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/tree-ssa/loop-20.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/tree-ssa-address.c branches/gcc-4_2-branch/gcc/tree.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29516
[Bug c++/30601] [4.3 regression] -Wreturn-type warns about more than what the documentation says
--- Comment #2 from bangerth at math dot tamu dot edu 2007-01-26 19:58 --- Subject: Re: [4.3 regression] -Wreturn-type warns about more than what the documentation says > Why am I in the CC list? I put you there. I assumed that the bug was introduced with your recent work on warnings. If that isn't the case: my apologies, and feel free to remove yourself from the CC: list again. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30601
[Bug c++/30603] wrong results - when long long varaible is multiplied with big number
--- Comment #1 from schwab at suse dot de 2007-01-26 20:04 --- (50L * rowsetSize * recordLength) overflows when long is a 32 bit type. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30603
[Bug tree-optimization/30604] New: Unable to coalesce ssa_names and which are marked as MUST COALESCE
Compiling the attached class file with -O results is: $ gcj -findirect-dispatch -O -c CppTreeParser.class Unable to coalesce ssa_names 7 and 8642 which are marked as MUST COALESCE. _t_7(ab) and _t_8642(ab) frysk/expr/CppTreeParser.java: In class 'frysk.expr.CppTreeParser': frysk/expr/CppTreeParser.java: In method 'frysk.expr.CppTreeParser.expr(antlr.collections.AST)': frysk/expr/CppTreeParser.java:0: internal compiler error: SSA corruption This only happens with -O. It compiles fine with 4.1.1. -- Summary: Unable to coalesce ssa_names and which are marked as MUST COALESCE Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mark at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30604
[Bug tree-optimization/30604] Unable to coalesce ssa_names and which are marked as MUST COALESCE
--- Comment #1 from mark at gcc dot gnu dot org 2007-01-26 20:35 --- Created an attachment (id=12965) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12965&action=view) Generated .class byte code file This is a generated .class file. It has been generated by gcj -C CppTreeParser.java (which uses ecj). The original .java source file was generated by antlr (and a little sed script) from cpp.g. Original available from the frysk project http://sourceware.org/cgi-bin/cvsweb.cgi/frysk-core/frysk/expr/cpp.g?cvsroot=frysk Other intermediary files available on request of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30604
[Bug c++/30601] [4.3 regression] -Wreturn-type warns about more than what the documentation says
--- Comment #3 from manu at gcc dot gnu dot org 2007-01-26 20:50 --- (In reply to comment #2) > Subject: Re: [4.3 regression] -Wreturn-type warns about more > than what the documentation says > > > > Why am I in the CC list? > > I put you there. I assumed that the bug was introduced with your recent > work on warnings. If that isn't the case: my apologies, and feel free to > remove yourself from the CC: list again. You assumed? Did I do something wrong? Well, anyway, I will look into it and try to find when we regressed. Please, next time use [EMAIL PROTECTED] Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30601
[Bug c/30581] Deeply inlined static functions break stack creation
--- Comment #12 from sqrammi at hotmail dot com 2007-01-26 21:10 --- This was confirmed to be a problem with alignment fixup in the kernel. Do an 'echo 2 > /proc/cpu/alignment' and misaligned accesses are fixed up, and this problem goes away. Misaligned accesses should IMHO not be completely ignored by default in the kernel, so I'll follow up with the ARM linux people. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30581
[Bug tree-optimization/29145] unsafe use of restrict qualifier
--- Comment #10 from djg at cray dot com 2007-01-26 21:09 --- (In reply to comment #8) > I'm testing this patch, that makes us more conservative, and concludes that > two > pointers don't overlap only if both are "based on" restricted pointers, with > "based on" trivially implemented as the pointer used in the reference itself. > In addition, we check that the declarations of both pointers are in the > parameter list of the same function (to be safe w.r.t the scope of the pointer > declarations). Looks like this should be safe enough? One thing I can think of that this description misses is that the two pointers must be based-on *different* restrict-qualified pointers, unless that case is already handled elsewhere. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29145
[Bug c++/30601] [4.3 regression] -Wreturn-type warns about more than what the documentation says
--- Comment #4 from bangerth at math dot tamu dot edu 2007-01-26 21:11 --- Subject: Re: [4.3 regression] -Wreturn-type warns about more than what the documentation says > You assumed? Did I do something wrong? I don't know. Possibly not. But the people who've been working in a certain area where a problem appears typically can make better guesses who might actually have introduced this bug. I'm not accusing you of having caused this. I'm just trying to get anyone knowledgable about the warning system to help find out who did :-) W. - Wolfgang Bangerthemail:[EMAIL PROTECTED] www: http://www.math.tamu.edu/~bangerth/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30601
[Bug c++/30601] [4.3 regression] -Wreturn-type warns about more than what the documentation says
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-26 21:13 --- (In reply to comment #4) > I'm not accusing you of having caused this. I'm just trying to get anyone > knowledgable about the warning system to help find out who did :-) > OK. That is fine. Just that I am new here and I would like to be told whether I am doing something wrong. I am running a regression hunt right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30601
[Bug c++/30601] [4.3 regression] -Wreturn-type warns about more than what the documentation says
--- Comment #6 from gdr at cs dot tamu dot edu 2007-01-26 21:21 --- Subject: Re: [4.3 regression] -Wreturn-type warns about more than what the documentation says "bangerth at math dot tamu dot edu" <[EMAIL PROTECTED]> writes: | Subject: Re: [4.3 regression] -Wreturn-type warns about more | than what the documentation says | | | > Why am I in the CC list? | | I put you there. I assumed that the bug was introduced with your recent | work on warnings. If that isn't the case: my apologies, and feel free to | remove yourself from the CC: list again. I believe it was introduced by someone else. The documentation needs fixing. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30601
[Bug middle-end/26061] error and warning count
--- Comment #6 from ismail at pardus dot org dot tr 2007-01-26 21:29 --- Maybe a better version could be like this, --- gcc/toplev.c2006-10-09 19:27:14.0 +0300 +++ gcc/toplev.c2007-01-26 20:59:19.395519510 +0200 @@ -1975,6 +1975,12 @@ /* Language-specific end of compilation actions. */ lang_hooks.finish (); + + + /* Print error / warning counts. */ + if ( errorcount || warningcount ) +fprintf (stderr, "\n%s: *** %d errors, %d warnings", + progname, errorcount, warningcount); } /* Initialize the compiler, and compile the input file. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26061
[Bug c++/30601] [4.3 regression] -Wreturn-type warns about more than what the documentation says
--- Comment #7 from gdr at cs dot tamu dot edu 2007-01-26 21:32 --- Subject: Re: [4.3 regression] -Wreturn-type warns about more than what the documentation says "manu at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | OK. That is fine. Just that I am new here and I would like to be | told whether I am doing something wrong. just assume people are less confrontational than it might appear. :-) -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30601
[Bug c++/30601] [4.3 regression] -Wreturn-type warns about more than what the documentation says
--- Comment #8 from bangerth at math dot tamu dot edu 2007-01-26 21:41 --- Subject: Re: [4.3 regression] -Wreturn-type warns about more than what the documentation says > just assume people are less confrontational than it might appear. :-) True. Gaby is probably willing to testify that I'm generally a rather mild-mannered person :-) - Wolfgang Bangerthemail:[EMAIL PROTECTED] www: http://www.math.tamu.edu/~bangerth/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30601
[Bug middle-end/26061] error and warning count
--- Comment #7 from manu at gcc dot gnu dot org 2007-01-26 21:59 --- Whatever version is fine for me. Gabriel, any preference? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26061
[Bug fortran/30605] New: -Wno-tabs should be active for -std=f2003 and -pedantic
-Wno-tabs according to the manual currently is active for -pedantic, -std=f95, and -Wall. It should be active for -std=f2003 as well. Finally, it's not actually active for -pedantic. % cat xtabs.f90 print *, "hi" end -std=f2003 and -pedantic don't work: % gfortran -std=f2003 xtabs.f90 % % gfortran -pedantic xtabs.f90 % -std=f95 and -Wall do work: % gfortran -std=f95 xtabs.f90 xtabs.f90:1.1: print *, "hi" 1 Warning: Nonconforming tab character at (1) % gfortran -Wall xtabs.f90 xtabs.f90:1.1: print *, "hi" 1 Warning: Nonconforming tab character at (1) -- Summary: -Wno-tabs should be active for -std=f2003 and -pedantic Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jb at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30605
[Bug c++/30601] [4.3 regression] -Wreturn-type warns about more than what the documentation says
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-01-26 22:51 --- I think this was done on purpose. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30601
[Bug c++/30601] [4.3 regression] -Wreturn-type warns about more than what the documentation says
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-01-26 22:52 --- See PR 18313 *** This bug has been marked as a duplicate of 18313 *** -- 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=30601
[Bug c++/18313] Missing warning for superfluous const's in return types
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-01-26 22:52 --- *** Bug 30601 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18313
[Bug c++/30601] [4.3 regression] -Wreturn-type warns about more than what the documentation says
--- Comment #11 from bangerth at math dot tamu dot edu 2007-01-26 22:59
---
Subject: Re: [4.3 regression] -Wreturn-type warns about more
than what the documentation says
> I think this was done on purpose.
It is contrary to what the documentation says. I think it also doesn't
make much sense in C++ if the return type results from a template
substitution. For example, the following case is rather common:
template class Array {
T& operator();
T operator() const;
};
This class will trigger a warning if instantiated as Array
because the return type of the second operator() is now 'const double'.
W.
-
Wolfgang Bangerthemail:[EMAIL PROTECTED]
www: http://www.math.tamu.edu/~bangerth/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30601
[Bug c++/30601] [4.3 regression] -Wreturn-type warns about more than what the documentation says
--- Comment #12 from manu at gcc dot gnu dot org 2007-01-26 23:00 --- Argh! Just when the regression hunt found the patch! So yes, it was on purpose. And the discussion + review is here: http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00792.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30601
[Bug c++/18313] Missing warning for superfluous const's in return types
--- Comment #6 from bangerth at dealii dot org 2007-01-26 23:01 ---
Hm, I'm not sure if I like this situation. Consider this snippet,
typical of template games:
---
template class Array {
T& operator();
T operator() const;
};
---
This class will trigger a warning if instantiated as Array
because the return type of the second operator() is now 'const double'.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18313
[Bug c++/18313] Missing warning for superfluous const's in return types
--- Comment #7 from manu at gcc dot gnu dot org 2007-01-26 23:04 --- Dirk, the patch is missing an update to doc/invoke.texi to reflect the changes. Would you mind to update it? Thanks. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org, ||mueller at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18313
[Bug c/30368] wrong result
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-26 23:14 --- (In reply to comment #4) > Subject: Re: wrong result > > "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: > > | > anther, consider an example definite[2] of 'offsetof', if you think > | > that is undefined, it's almost impossible to give a definite of > | > offsetof. > | > | > #define offsetof(TYPE,MEMBER) ((size_t)&((TYPE*)0)->MEMBER) > | > | The C standard still says that is undefined. See 6.5.3.2/4. > | Also GCC has a builtin for offsetof to get around the undefinedness of the > | above. > > The C front-end should probably warn -- the C++ front-end does. Does it? With which options? I wasn't able to get a warning or error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30368
[Bug middle-end/26061] error and warning count
--- Comment #8 from hyperquantum at gmail dot com 2007-01-26 23:18 --- I prefer the second version. The output is only useful in case there are errors or warnings, not when you have a flawless compilation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26061
[Bug libgcj/30606] New: natVMURLConnection.cc:21: error: 'magic_t' does not name a type t name a type
/test/gnu/gcc/objdir/./gcc/xgcc -shared-libgcc -B/test/gnu/gcc/objdir/./gcc
-nos
tdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src
-L/test/gn
u/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs
-B/opt/gnu/gcc/gcc-4.3
.0/hppa2.0w-hp-hpux11.11/bin/
-B/opt/gnu/gcc/gcc-4.3.0/hppa2.0w-hp-hpux11.11/lib
/ -isystem /opt/gnu/gcc/gcc-4.3.0/hppa2.0w-hp-hpux11.11/include -isystem
/opt/gn
u/gcc/gcc-4.3.0/hppa2.0w-hp-hpux11.11/sys-include -DHAVE_CONFIG_H -I.
-I../../..
/gcc/libjava -I./include -I./gcj -I../../../gcc/libjava -Iinclude
-I../../../gcc
/libjava/include -I../../../gcc/libjava/classpath/include -Iclasspath/include
-I
../../../gcc/libjava/classpath/native/fdlibm
-I../../../gcc/libjava/../boehm-gc/
include -I../boehm-gc/include -I../../../gcc/libjava/libltdl
-I../../../gcc/libj
ava/libltdl -I../../../gcc/libjava/.././libjava/../gcc
-I../../../gcc/libjava/..
/zlib -I../../../gcc/libjava/../libffi/include -I../libffi/include -fno-rtti
-fn
on-call-exceptions -pthread -fdollars-in-identifiers -Wswitch-enum
-D_FILE_OFFSE
T_BITS=64 -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\"/opt/gnu/gcc/gcc-4.3.0\"
-DTOOL
EXECLIBDIR=\"/opt/gnu/gcc/gcc-4.3.0/lib\"
-DJAVA_HOME=\"/opt/gnu/gcc/gcc-4.3.0\"
-DBOOT_CLASS_PATH=\"/opt/gnu/gcc/gcc-4.3.0/share/java/libgcj-4.3.0.jar\"
-DJAVA
_EXT_DIRS=\"/opt/gnu/gcc/gcc-4.3.0/share/java/ext\"
-DGCJ_ENDORSED_DIRS=\"/opt/g
nu/gcc/gcc-4.3.0/share/java/gcj-endorsed\"
-DGCJ_VERSIONED_LIBDIR=\"/opt/gnu/gcc
/gcc-4.3.0/lib/gcj-4.3.0\" -DPATH_SEPARATOR=\":\"
-DLIBGCJ_DEFAULT_DATABASE=\"/o
pt/gnu/gcc/gcc-4.3.0/lib/gcj-4.3.0/classmap.db\"
-DLIBGCJ_DEFAULT_DATABASE_PATH_
TAIL=\"gcj-4.3.0/classmap.db\" -g -O2 -MT java/net/natVMURLConnection.lo -MD
-MP
-MF java/net/.deps/natVMURLConnection.Tpo -c
../../../gcc/libjava/java/net/natV
MURLConnection.cc -fPIC -DPIC -o java/net/.libs/natVMURLConnection.o
../../../gcc/libjava/java/net/natVMURLConnection.cc:21: error: 'magic_t' does
no
t name a type
../../../gcc/libjava/java/net/natVMURLConnection.cc:23: error: ISO C++ forbids
d
eclaration of 'magic_t' with no type
../../../gcc/libjava/java/net/natVMURLConnection.cc:23: error: 'p_magic_open'
wa
s not declared in this scope
../../../gcc/libjava/java/net/natVMURLConnection.cc:23: error: expected ',' or
'
;' before '(' token
../../../gcc/libjava/java/net/natVMURLConnection.cc:24: error: expected `)'
befo
re 'cookie'
../../../gcc/libjava/java/net/natVMURLConnection.cc:24: error: expected
primary-
expression before 'const'
../../../gcc/libjava/java/net/natVMURLConnection.cc:24: error: initializer
expre
ssion list treated as compound expression
../../../gcc/libjava/java/net/natVMURLConnection.cc:25: error: expected `)'
befo
re 'cookie'
../../../gcc/libjava/java/net/natVMURLConnection.cc:25: error: invalid
conversio
n from 'int' to 'void*'
../../../gcc/libjava/java/net/natVMURLConnection.cc:26: error: expected `)'
befo
re 'cookie'
../../../gcc/libjava/java/net/natVMURLConnection.cc:26: error: expected
primary-
expression before 'const'
../../../gcc/libjava/java/net/natVMURLConnection.cc:27: error: expected
primary-
expression before 'length'
../../../gcc/libjava/java/net/natVMURLConnection.cc:27: error: initializer
expre
ssion list treated as compound expression
../../../gcc/libjava/java/net/natVMURLConnection.cc: In static member function
'
static void java::net::VMURLConnection::init()':
../../../gcc/libjava/java/net/natVMURLConnection.cc:39: error: 'p_magic_open'
wa
s not declared in this scope
../../../gcc/libjava/java/net/natVMURLConnection.cc:52: error: 'cookie' was not
declared in this scope
../../../gcc/libjava/java/net/natVMURLConnection.cc:52: error: 'MAGIC_MIME' was
not declared in this scope
../../../gcc/libjava/java/net/natVMURLConnection.cc:53: error: expected `)'
befo
re '__null'
../../../gcc/libjava/java/net/natVMURLConnection.cc:55: error: 'p_magic_load'
ca
nnot be used as a function
../../../gcc/libjava/java/net/natVMURLConnection.cc:57: error: 'p_magic_close'
c
annot be used as a function
../../../gcc/libjava/java/net/natVMURLConnection.cc:58: error: expected `;'
befo
re '__null'
../../../gcc/libjava/java/net/natVMURLConnection.cc: In static member function
'
static java::lang::String*
java::net::VMURLConnection::guessContentTypeFromBuffe
r(JArray<__java_byte>*, jint)':
../../../gcc/libjava/java/net/natVMURLConnection.cc:70: error: 'cookie' was not
declared in this scope
../../../gcc/libjava/java/net/natVMURLConnection.cc:70: error: expected `)'
befo
re '__null'
../../../gcc/libjava/java/net/natVMURLConnection.cc:73: error: 'cookie' was not
declared in this scope
../../../gcc/libjava/java/net/natVMURLConnection.cc:73: error: 'p_magic_buffer'
cannot be used as a function
make[3]: *** [java/net/natVMURLConnection.lo] Error 1
On HP-UX 11.11, magic.h doesn't define magic_t, etc.
--
Summary: natVMURLConnection.cc:21: error: 'magic_t' does not name
a type
t name a type
Product: gcc
Version: 4.3.0
St
[Bug middle-end/26061] error and warning count
--- Comment #9 from ismail at pardus dot org dot tr 2007-01-26 23:29 --- There should also be a newline, --- gcc/toplev.c2006-10-09 19:27:14.0 +0300 +++ gcc/toplev.c2007-01-26 20:59:19.395519510 +0200 @@ -1975,6 +1975,12 @@ /* Language-specific end of compilation actions. */ lang_hooks.finish (); + + + /* Print error / warning counts. */ + if ( errorcount || warningcount ) +fprintf (stderr, "\n%s: *** %d errors, %d warnings\n", + progname, errorcount, warningcount); } /* Initialize the compiler, and compile the input file. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26061
[Bug middle-end/30494] ICE with VLA and openmp
--- Comment #4 from jakub at gcc dot gnu dot org 2007-01-26 23:45 --- Fixed in SVN. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30494
[Bug middle-end/30421] incorrect warning when using firstprivate and lastprivate clauses
--- Comment #7 from jakub at gcc dot gnu dot org 2007-01-26 23:46 --- Fixed in SVN. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30421
[Bug middle-end/27416] ICE on invalid firstprivate/lastprivate
--- Comment #8 from jakub at gcc dot gnu dot org 2007-01-26 23:46 --- Fixed in SVN. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27416
[Bug c++/13657] Error message incorrectly describes return type as argument type
--- Comment #2 from manu at gcc dot gnu dot org 2007-01-26 23:47 ---
(In reply to comment #0)
> The error message is basically correct, but there is no `argument' here. The
> error message should refer to the return type instead. It might suffice to
> simply replace the word `argument' with the word `return'.
It is not that easy. The function that emits the error seems to be used for
several things. However, at the point that the error is issued, I don't see any
way to detect what we are actually doing.
What do you think about this message? Will it work for any situation?
error: C::bar of type int (C::)() does not match expected type int (*)()
The patch would be something like:
- error ("argument of type %qT does not match %qT", TREE_TYPE (rhs), lhstype);
+ error ("%qE of type %qT does not match expected type %qT", rhs,
TREE_TYPE(rhs), lhstype)
Andrew? Gabriel? Ian?
I can implement it and test it if you agree.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13657
[Bug fortran/30605] -Wno-tabs should be active for -std=f2003 and -pedantic
--- Comment #1 from kargl at gcc dot gnu dot org 2007-01-27 00:01 --- Created an attachment (id=12966) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12966&action=view) untested patch Here's an untested patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30605
[Bug fortran/30605] -Wno-tabs should be active for -std=f2003 and -pedantic
--- Comment #2 from kargl at gcc dot gnu dot org 2007-01-27 00:02 --- Confirmed. I just attached an untested patch. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-27 00:02:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30605
[Bug bootstrap/30510] [4.3 Regression] Gcc failed to bootstrap
--- Comment #15 from hjl at lucon dot org 2007-01-27 00:02 --- Created an attachment (id=12967) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12967&action=view) Part of cp/parser.c without --enable-checking=assert This is the part of cp/parser.c configured without --enable-checking=assert. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510
[Bug bootstrap/30510] [4.3 Regression] Gcc failed to bootstrap
--- Comment #16 from hjl at lucon dot org 2007-01-27 00:06 --- Created an attachment (id=12968) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12968&action=view) Part of cp/parser.c with --enable-checking=assert This is the part of cp/parser.c configured with --enable-checking=assert. Because different -enable-checking settings effectively create slightly different gcc source codes seen by gcc, gcc may or may not be determine bases will be initialized or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510
[Bug libgomp/30546] [4.3 regression] build fail in libgomp because makeinfo is missing
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-01-27 00:08 --- My doings. I'll look into it. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-01-26 13:07:27 |2007-01-27 00:08:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30546
[Bug libgomp/30546] [4.3 regression] build fail in libgomp because makeinfo is missing
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-01-27 00:34 --- As far as I can tell, the BUILD_INFO conditional can not easily be employed as the info, dvi and pdf targets are generated by automake. The `missing` program that is run instead should step into the breach. It does, but: gcc/missing, line 300-303: # If the file does not exist, the user really needs makeinfo; # let's fail without touching anything. test -f $file || exit 1 touch $file Thus, two options present themself: ditch automake generated targets, do it manually as everywhere else or tweak the Makefile.am to touch libgomp.info before invoking `missing makeinfo`. Preferences? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30546
Re: [Bug libgomp/30546] [4.3 regression] build fail in libgomp because makeinfo is missing
> Thus, two options present themself: ditch automake generated targets, do it > manually as everywhere else or tweak the Makefile.am to touch libgomp.info > before invoking `missing makeinfo`. > > Preferences? This only matters when building from SVN. I say we should just require makeinfo and forget about the problem. -- Pinski
[Bug libgomp/30546] [4.3 regression] build fail in libgomp because makeinfo is missing
--- Comment #6 from pinskia at physics dot uc dot edu 2007-01-27 00:37 --- Subject: Re: [4.3 regression] build fail in libgomp because makeinfo is missing > Thus, two options present themself: ditch automake generated targets, do it > manually as everywhere else or tweak the Makefile.am to touch libgomp.info > before invoking `missing makeinfo`. > > Preferences? This only matters when building from SVN. I say we should just require makeinfo and forget about the problem. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30546
[Bug java/30607] New: gcj -I x -C doesn't include x as source dir search patch
Given an directory x with two source files:
- x/a.java
public class a extends b { }
- x/b.java
public class b { }
With gcj 4.1.1 it was possible to include x as source patch search dir with -I
and compile as follows:
$ gcj -C -I x x/a.java
With current svn trunk (and ecj1 installed) this gives:
$ /usr/local/gcc43/bin/gcj -C -I x x/a.java
x/a.java:1: error: b cannot be resolved to a type
public class a extends b { }
^
1 problem (1 error)
--
Summary: gcj -I x -C doesn't include x as source dir search patch
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mark at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30607
[Bug fortran/30605] -Wno-tabs should be active for -std=f2003 and -pedantic
--- Comment #3 from kargl at gcc dot gnu dot org 2007-01-27 00:45 --- Testing the patch shows -pedantic has found some invalid code in the testsuite. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30605
[Bug c/11051] -Wno-deprecated needed also for C
--- Comment #9 from manu at gcc dot gnu dot org 2007-01-27 01:02 ---
(In reply to comment #8)
> Subject: Re: -Wno-deprecated needed also for C
>
> > manu at gcc dot gnu dot org wrote:
> > > --- Comment #4 from manu at gcc dot gnu dot org 2007-01-23 00:01
> > > ---
> > > The testcase given is not valid any more. Could you think in any other
> > > testcase?
> > >
> > > In stmt.c (expand_asm_operands) there is:
> > >
> > > warning (0, "use of memory input without lvalue in "
> > >"asm operand %d is deprecated", i + noutputs);
> > >
> > >
> >
> > Hang on, hang on...
> >
> > WTF?! Using an rvalue in an assembly input that may contain "m" is
> > something that is highly useful, and it will break metric tons of code.
> > -Wno-deprecated or no -Wno-deprecated, deprecating this particular
> > construct is a major mistake.
>
> This has been true since 3.3.3 and in fact, this was made an error in 4.0.0,
> even though the warning remains.
Huh? What is that suppose to mean?
> So:
> float f(float a)
> {
> asm(""::"mo"((double)a));
> return a;
> }
>
> Fails
But it doesn't produce that warning. Is that warning dead code or what?
Still, going back to this PR, is there anything deprecated in C front-end worth
of implementing -Wno-deprecated for C?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11051
[Bug c/11051] -Wno-deprecated needed also for C
--- Comment #10 from hpa at zytor dot com 2007-01-27 01:09 --- Subject: Re: -Wno-deprecated needed also for C manu at gcc dot gnu dot org wrote: > > But it doesn't produce that warning. Is that warning dead code or what? > Apparently so. I think it should have stayed a warning, but that's a long time gone, and is way too late to fix now. I'm going to submit a doc patch, since this change was never documented. -hpa -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11051
[Bug libgomp/30546] [4.2/4.3 regression] build fail in libgomp because makeinfo is missing
--- Comment #7 from dfranke at gcc dot gnu dot org 2007-01-27 01:11 --- Third option: include libgomp.info in SVN, then `missing` will just touch it. Please note: I backported the docs two days ago, 4.2 is now also affected. Did not know this report existed =( -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3 regression] build fail |[4.2/4.3 regression] build |in libgomp because makeinfo |fail in libgomp because |is missing |makeinfo is missing Target Milestone|4.3.0 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30546
[Bug c/11051] -Wno-deprecated needed also for C
--- Comment #11 from manu at gcc dot gnu dot org 2007-01-27 01:38 --- (In reply to comment #10) > Subject: Re: -Wno-deprecated needed also for C > > manu at gcc dot gnu dot org wrote: > > > > But it doesn't produce that warning. Is that warning dead code or what? > > > > Apparently so. I think it should have stayed a warning, but that's a > long time gone, and is way too late to fix now. I'm going to submit a > doc patch, since this change was never documented. > Wouldn't it be better to remove the dead code? Or is there a policy against touching things that are not broken? I think that at least one comment on the code would be appropriate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11051
