[Bug libfortran/24909] libmatmul.a breaks darwin build
--- Comment #2 from jb at gcc dot gnu dot org 2005-11-17 08:26 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01271.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24909
[Bug debug/21932] [3.4 Regression] -O3 -fno-unit-at-a-time causes ICE
--- Comment #3 from reichelt at gcc dot gnu dot org 2005-11-17 09:40 --- The compiler already crashes with "g++ -O -finline-functions -g", i.e. without explicitly specifying -fno-unit-at-a-time. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Keywords||monitored http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21932
[Bug fortran/24862] [4.1 Regression] Internal Error: Derived type I/O should have been handled via the frontend.
--- Comment #5 from jb at gcc dot gnu dot org 2005-11-17 10:00 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01277.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24862
[Bug c++/24849] [gomp] ICE in expand_expr_real_1
--- Comment #5 from reichelt at gcc dot gnu dot org 2005-11-17 10:02
---
Here's a shorter testcase without templates:
==
void foo()
{
#pragma omp parallel
{
int i, N;
#pragma omp for schedule (dynamic)
for (i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=24849
[Bug rtl-optimization/24883] [4.1 Regression] fatal error: internal consistency failure building xorg-x11
--- Comment #3 from saurabh dot verma at codito dot com 2005-11-17 10:05 --- Adding myself to CC list, as the offending patch was given by me -- saurabh dot verma at codito dot com changed: What|Removed |Added CC||saurabh dot verma at codito ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24883
[Bug c++/24791] ICE on invalid instantiation of template's static member
--- Comment #1 from reichelt at gcc dot gnu dot org 2005-11-17 10:39
---
Confirmed.
The following code snippet causes an ICE since 2.95.3
with the exception of 4.0.0 - 4.0.2:
==
template struct A
{
static int i;
A() { ++i; }
};
template int A<0>::i(0);
A<0> a;
==
The following variation causes an ICE since 4.0.0 (and before 3.1)
and is accepted by GCC 3.1 - 3.4.5:
==
template struct A
{
static int i;
};
template int A<0>::i(0);
==
--
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||accepts-invalid, monitored
Known to fail|2.95.3 3.0.4|
Last reconfirmed|-00-00 00:00:00 |2005-11-17 10:39:17
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24791
[Bug c++/24278] [3.4/4.0/4.1 regression] ICE while trying to print out error
--- Comment #6 from reichelt at gcc dot gnu dot org 2005-11-17 11:08
---
The following testcase crashes since GCC 2.95.3 except 3.1 and 3.2:
===
template struct A
{
A() : T(0) {}
};
A a;
===
The error message with GCC 3.2 was:
bug.cc: In constructor `A::A() [with T = int*]':
bug.cc:6: instantiated from here
bug.cc:3: type `int*' is not a base type for type `A'
So we have a regression.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Keywords||monitored
Known to fail|3.4.5 4.0.2 4.1.0 3.3.3 |3.4.5 4.0.2 4.1.0 2.95.3
|3.0.4 2.95.3|3.0.4 3.2.1 3.2.3 3.3.6
Known to work||3.1 3.2
Summary|ICE while trying to print |[3.4/4.0/4.1 regression] ICE
|out error |while trying to print out
||error
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24278
[Bug ada/24857] ada/s-auxdec.ads alignment issue for arm-rtems
--- Comment #2 from guerby at gcc dot gnu dot org 2005-11-17 11:13 --- Subject: Bug 24857 Author: guerby Date: Thu Nov 17 11:13:18 2005 New Revision: 107116 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107116 Log: 2005-11-17 Laurent GUERBY <[EMAIL PROTECTED]> PR ada/24857 * s-auxdec-empty.ads, s-auxdec-empty.adb: New files. Added: trunk/gcc/ada/s-auxdec-empty.adb trunk/gcc/ada/s-auxdec-empty.ads Modified: trunk/gcc/ada/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24857
[Bug c++/24439] ICE with invert conditional containing throw
--- Comment #14 from reichelt at gcc dot gnu dot org 2005-11-17 11:24 --- This is not really a regression, since evn with 2.95.3 we get an ICE (with --enable-checking): bug.cc: In function `int main()': bug.cc:4: converting to `void' from `int' bug.cc:4: void value not ignored as it ought to be bug.cc:4: ../../gcc-2.95.3/gcc/fold-const.c:2095: Expect 't', have 'error_mark' The last line is in fact an ICE. So 2.95.3 wrongly reports an error and ICE's afterwards. Since we don't have a regression, I'm closing the PR. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Status|NEW |RESOLVED Resolution||FIXED Summary|[3.4/4.0 Regression] ICE|ICE with invert conditional |with invert conditional|containing throw |containing throw| Target Milestone|4.0.3 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24439
[Bug middle-end/24851] [4.1 Regression] f2c miscompilation
--- Comment #18 from rguenth at gcc dot gnu dot org 2005-11-17 11:35 --- Subject: Bug 24851 Author: rguenth Date: Thu Nov 17 11:35:00 2005 New Revision: 107117 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107117 Log: 2005-11-16 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/24851 * fold-const.c (extract_array_ref): Return byte offset in all cases. (fold_binary): Fold &x[a] CMP &x[b] to a*sizeof(*x) CMP b*sizeof(*x) to get correct overflow behavior. * gcc.c-torture/execute/pr24851.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr24851.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug middle-end/24851] [4.1 Regression] f2c miscompilation
--- Comment #19 from rguenth at gcc dot gnu dot org 2005-11-17 11:36 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24851
[Bug target/24626] [4.1 Regression] internal compiler error: verify_flow_info failed
--- Comment #5 from rguenth at gcc dot gnu dot org 2005-11-17 11:42 --- So I guess being able to hunt it confirms it. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-17 11:42:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
[Bug rtl-optimization/24823] [4.1 Regression] ICE in insert_save, at caller-save.c:719
--- Comment #6 from rguenth at gcc dot gnu dot org 2005-11-17 11:47 --- Btw., this also happens on armv4l compiling NX: gcc -c -O3 -fsigned-char -I. -I../../exports/include/freetype2 -I../../extras/freetype2/src-I../../extras/freetype2/src/base -I../../extras/freetype2/src/autohint -I../../extras/freetype2/src/bdf -I../../extras/freetype2/src/cff-I../../extras/freetype2/src/cid -I../../extras/freetype2/src/pcf-I../../extras/freetype2/src/pfr -I../../extras/freetype2/src/psaux -I../../extras/freetype2/src/pshinter -I../../extras/freetype2/src/psnames-I../../extras/freetype2/src/raster -I../../extras/freetype2/src/sfnt -I../../extras/freetype2/src/smooth -I../../extras/freetype2/src/truetype -I../../extras/freetype2/src/type1 -I../../extras/freetype2/src/type42 -I../../extras/freetype2/src/winfonts -I../.. -I../../exports/include -Dlinux -D__arm__ -D__arm32__ -U__arm -Uarm -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API bdf.c ../../extras/freetype2/src/bdf/bdfdrivr.c: In function 'BDF_Face_Init': ../../extras/freetype2/src/bdf/bdfdrivr.c:285: internal compiler error: in insert_save, at caller-save.c:719 Please submit a full bug report, with preprocessed source if appropriate. See http://www.suse.de/feedback> for instructions. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|x86_64-*-linux-gnu |x86_64-*-linux-gnu, armv4l- ||*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24823
[Bug c++/24602] g++: Internal error: Illegal instruction (program cc1plus)
--- Comment #7 from reichelt at gcc dot gnu dot org 2005-11-17 11:59
---
Here's a sightly simpler testcase.
If I remove the copy-ctor from A, I get the failure from PR24606.
=
template void foo(F f)
{
f();
}
struct A
{
A();
A(const A&);
};
template void bar(A = A());
void baz()
{
foo(bar<0>);
}
=
Btw, removing the template from "bar" makes the code compile.
So it seems like the code is valid after all.
--
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||ice-on-valid-code, monitored
Last reconfirmed|-00-00 00:00:00 |2005-11-17 11:59:15
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24602
[Bug c++/24606] ICE on template function which gets an template agrument as a function with a default argument
--- Comment #2 from reichelt at gcc dot gnu dot org 2005-11-17 12:04 --- I think this is a duplicate of PR 24602. The only difference is the missing copy-ctor here. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Keywords||ice-on-valid-code, monitored http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24606
[Bug fortran/24793] [4.1 Regression] ICE: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:746
--- Comment #6 from rakdver at gcc dot gnu dot org 2005-11-17 12:33 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01283.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||11/msg01283.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24793
[Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred
--- Comment #22 from thebohemian at gmx dot net 2005-11-17 12:39 --- Created an attachment (id=10262) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10262&action=view) lazy linking - part 2 This is the same patch as above but corrects the behavior in case that the static field of a missing class is touched. Anyway I missed setting the JV_CONSTANTS_Resolved flag after the creation of the phantom class and had to add special handling for the case that the owner of a field is such a phantom class (-> throw NoClassDefFoundError, as always ;) ) -- thebohemian at gmx dot net changed: What|Removed |Added Attachment #10255|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
[Bug rtl-optimization/24883] [4.1 Regression] fatal error: internal consistency failure building xorg-x11
--- Comment #4 from uweigand at gcc dot gnu dot org 2005-11-17 12:45 --- It looks like the simplify-rtx patch is not really the cause of the problem, it simply exposes a pre-existing bug in combine and/or flow. Before combine, we have a situation that looks like (simplified): insn 82: reg46 = reg49 ^ reg50 (REG_DEAD reg49) insn 87: reg50 = reg46 ^ reg50 (REG_READ reg46) Note that reg 50 is live both at the start and the end of the current basic block. Now, due to the improved XOR optimization in simplify-rtx, combine recognized these insn can be combined into: insn 87: reg50 = reg49 (REG_READ reg49) And suddenly reg50 is no longer live at the start of this basic block. Unfortunately, there appears to be no code in combine that recognizes this fact and schedules the basic block for updating of global life info. (The only cases where that happens are related to moving REG_DEAD notes, but in this situation we don't *have* a REG_DEAD note for reg50 in the first place.) Thus, reg50 remains marked live-at-start in this basic block, and when a later pass does a local live info update on the block, the sanity check in verify_local_life_at_start triggers. Right now I don't know how and where to fix this. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-17 12:45:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24883
[Bug libfortran/24892] ACCESS argument to the OPEN statement
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2005-11-17 12:47 --- Subject: Bug 24892 Author: fxcoudert Date: Thu Nov 17 12:46:57 2005 New Revision: 107119 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107119 Log: PR fortran/24892 * io/io.h (unit_access): Add ACCESS_APPEND. * io/open.c (access_opt): Add APPEND value for ACCESS keyword. (st_open): Use that new value to set the POSITION accordingly. * gfortran.dg/open_access_append_1.f90: New test. * gfortran.dg/open_access_append_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/open_access_append_1.f90 trunk/gcc/testsuite/gfortran.dg/open_access_append_2.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/io.h trunk/libgfortran/io/open.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24892
[Bug fortran/20811] gfortran include problem (regression from g77)
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2005-11-17 12:51 --- Subject: Bug 20811 Author: fxcoudert Date: Thu Nov 17 12:51:41 2005 New Revision: 107120 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107120 Log: PR fortran/20811 * scanner.c (gfc_open_included_file): Add an extra include_cwd argument. Only include files in the current working directory if its value is true. * gfortran.h: Change prototype for gfc_open_included_file. (load_file): Don't search for include files in the current working directory. * options.c (gfc_post_options): Add the directory of the source file to the list of paths for included files. * module.c (gfc_use_module): Look for module files in the current directory. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/module.c trunk/gcc/fortran/options.c trunk/gcc/fortran/scanner.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20811
[Bug target/19923] [4.0/4.1 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
--- Comment #34 from rakdver at gcc dot gnu dot org 2005-11-17 13:35 --- It behaves somewhat erratically on SPEC2000 (it increases the overall score, but there are some significant regressions). And, it also causes us to produce worse code for this testcase at the moment, due to a missunderstanding between ivopts and fold; expression (unsigned char) (signed char) (int) (ptr + 1B) - (unsigned char) ptr is produced, and it is not folded to 1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred
--- Comment #23 from aph at gcc dot gnu dot org 2005-11-17 13:46 --- mm, I was wrong about static fields. The problem is that a JV_CONSTANT_Fieldref constant pool entry points to a JV_CONSTANT_Class, and at the present time we attempt to resolve that JV_CONSTANT_Class reference at link time rather than at runtime. If we had used a JV_CONSTANT_String instead of a JV_CONSTANT_Class to represent a class in a JV_CONSTANT_Fieldref this would have worked. Oh well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
[Bug target/24757] [4.1 Regression] __sync_fetch_and_add on ia64
--- Comment #8 from pcarlini at suse dot de 2005-11-17 13:50 ---
I have got additional evidence that __sync_fetch_and_add does not work
correctly. If, for example, in this code, stressed in the testcase
12658_thread-1.cc, and using atomic operations:
const locale&
locale::operator=(const locale& __other) throw()
{
__other._M_impl->_M_add_reference();
_M_impl->_M_remove_reference();
_M_impl = __other._M_impl;
return *this;
}
I wrap everything in the locale_cons mutex then the testcase doesn't fail
anymore.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24757
[Bug classpath/23183] SimpleDateFormat fails to render '' as single quotes
--- Comment #8 from mark at gcc dot gnu dot org 2005-11-17 14:03 --- Subject: Bug 23183 Author: mark Date: Thu Nov 17 14:03:22 2005 New Revision: 107121 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107121 Log: 2005-11-17 Mark Wielaard <[EMAIL PROTECTED]> * java/text/SimpleDateFormat.java: Removed, fully merged now. * sources.am: Regenerated. * Makefile.in: Regenerated. 2005-11-17 Sven de Marothy <[EMAIL PROTECTED]> * java/text/SimpleDateFormat.java (computeOffset): Allow timezone to be first in the parsed String. 2005-11-17 Mark Wielaard <[EMAIL PROTECTED]> * java/text/SimpleDateFormat.java (field, size): Make package private. 2005-11-17 Tom Tromey <[EMAIL PROTECTED]> * java/text/SimpleDateFormat.java (compileFormat): Correctly handle quoted single quotes. PR classspath/23183. 2005-11-17 Tom Tromey <[EMAIL PROTECTED]> * java/text/SimpleDateFormat.java (compileFormat): Reformatted. 2005-11-17 Tom Tromey <[EMAIL PROTECTED]> * java/text/DateFormat.java (serialVersionUID): New field. 2005-11-17 Mark Wielaard <[EMAIL PROTECTED]> * java/text/DateFormat.java (equals): Reimplement. 2005-11-17 David Gilbert <[EMAIL PROTECTED]> * java/text/Collator.java: API doc fixes, * java/text/DateFormat.java: likewise, * java/text/DecimalFormatSymbols.java: likewise, * java/text/DateFormatSymbols.java: likewise, * java/text/SimpleDateFormat.java: likewise. 2005-11-17 Jeroen Frijters <[EMAIL PROTECTED]> * java/text/Collator.java (getInstance(Locale)): Added default collation pattern to handle case when resource is missing and throw InternalError instead of returning null should parsing fail. Removed: trunk/libjava/java/text/SimpleDateFormat.java Modified: trunk/libjava/ChangeLog trunk/libjava/Makefile.in trunk/libjava/java/text/Collator.java trunk/libjava/java/text/DateFormat.java trunk/libjava/java/text/DateFormatSymbols.java trunk/libjava/java/text/DecimalFormatSymbols.java trunk/libjava/sources.am -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23183
[Bug libfortran/24909] libmatmul.a breaks darwin build
--- Comment #3 from andreast at gcc dot gnu dot org 2005-11-17 14:37 --- Unfortunately it does not werk :( I found this message in the libtool archive: http://lists.gnu.org/archive/html/libtool-patches/2004-08/msg2.html Currently we have this 'whole_archive_flag_spec='-all_load $convenience'' in gcc-root/ltcf-c.sh (for darwin) Is this needed somehwere? Maybe we could remove this -all_load $convenience' entry in the ltcf-c.sh? Geoff? Doing so by hand in the gfortran libtool makes the library link. -- andreast at gcc dot gnu dot org changed: What|Removed |Added CC||geoffk at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24909
[Bug target/19923] [4.0/4.1 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
--- Comment #35 from rakdver at gcc dot gnu dot org 2005-11-17 15:09
---
Created an attachment (id=10263)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10263&action=view)
Patch
After some playing with fold, I arrived to the following patch, that almost
works. With the patch, the code for the loop is
:;
MEM[base: ptr]{*ptr} = cleanse_ctr;
ptr = ptr + 1B;
cleanse_ctr = (unsigned char) (((signed char) ptr & 15) + (signed char)
cleanse_ctr + 17);
len = len - 1;
if (len != 0) goto ; else goto ;
Which seems just fine. The assembler is
.L3:
movb(%edi), %al
movb%al, (%ecx)
incl%ecx
movb%cl, %al
andl$15, %eax
movb(%edi), %dl
addl$17, %edx
addl%edx, %eax
movb%al, (%edi)
decl%esi
jne .L3
Which also seems OK to me. However, the "ugly" version we produce without the
patch:
.L4:
movb(%edi), %al
movb%al, (%ecx)
incl%ecx
movb-16(%ebp), %al
addl%esi, %eax
andl$15, %eax
movb(%edi), %dl
addl$17, %edx
addl%edx, %eax
movb%al, (%edi)
incl%esi
cmpl12(%ebp), %esi
jne .L4
Is faster by 30%, from reasons I just don't understand :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug ada/15919] Compiler enters infinite loop on illegal program
--- Comment #2 from charlet at gcc dot gnu dot org 2005-11-17 15:15 --- Works fine on mainline as of today. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15919
[Bug tree-optimization/24793] [4.1 Regression] ICE: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:746
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-11-17 15:16 --- Not a frontend bug. P3. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|fortran |tree-optimization Priority|P5 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24793
[Bug ada/24855] Missing stdarg.h in ada/raise.c for arm-rtems
--- Comment #3 from charlet at gcc dot gnu dot org 2005-11-17 15:17 --- Closing. -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24855
[Bug tree-optimization/23202] [4.1 Regression] internal compiler error: tree check: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:746
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-11-17 15:17 --- Not a fortran frontend bug, but IVOPTs one. P3. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|fortran |tree-optimization Priority|P5 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23202
[Bug target/24779] [4.0 Regression] Python miscompilation - TOC reload
--- Comment #9 from dje at watson dot ibm dot com 2005-11-17 15:17 --- Subject: Re: [4.0 Regression] Python miscompilation - TOC reload "Reliably" is the wrong word. The patch will fix the problem reliably for the default case; it will not fix it for a particular set of options. The remaining problem is seeing constants through TOC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24779
[Bug ada/21629] [doc] gnat version requirements in install.texi
--- Comment #1 from charlet at gcc dot gnu dot org 2005-11-17 15:23 --- The minimum requirement is not out of date. There has indeed always been a different requirement for cross compilers where you need to first have a native compiler using the exact same version, and that should indeed be mentioned in the doc, in addition to the existing statement which seems correct to me. Feel free to submit a patch to that effect. Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |trivial http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21629
[Bug c++/9436] [ABI] passing a class template followed by a template value of this class
--- Comment #7 from reichelt at gcc dot gnu dot org 2005-11-17 15:23
---
Giovanni's example now compiles on mainline and the 4.0 branch
due to Mark's patch for PR 23789:
==
template struct A {};
template void foo(A) {}
void bar()
{
foo(A());
}
==
However, I still get "sorry, unimplemented" for the following testcase
which is closer to the original one:
==
template struct A {};
template void foo(A) {}
void bar()
{
foo(A());
}
==
bug.cc: In function 'void foo(A) [with T = char]':
bug.cc:3: sorry, unimplemented: zero-operand casts cannot be mangled due to a
defect in the C++ ABI
Note that "T()" is not a cast, but a default-constructed object.
A related problem is shown by the following testcase:
==
template struct A {};
A a;
==
bug.cc:3: error: type/value mismatch at argument 1 in template parameter list
for `template > struct A'
bug.cc:3: error: expected a constant of type `int', got `int ()()'
bug.cc:3: error: invalid type in declaration before ';' token
Obviously "int()" is not interpreted as "0", but as a function "int ()()".
Maybe "T()" in the example above causes the same problems.
Btw, icc compiles all testcases without problems.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||mark at codesourcery dot com
Keywords|ice-on-valid-code |rejects-valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9436
[Bug rtl-optimization/24912] New: m68k build failure: ICE: in reload_cse_simplify_operands
m68k-elf build fails building libiberty/regex.c.
Reduced testcase below:
void foo(void);
void
bar (unsigned char *p)
{
int j;
j = *(p) ;
j += ((signed char) (*p) ) << 8;
if (j)
foo();
}
Compiled with m68-elf-gcc -O2 gives
test.c:10: error: insn does not satisfy its constraints:
(insn 40 16 41 0 (set (reg:SI 2 %d2)
(sign_extend:SI (reg:HI 0 %d0 [34]))) 65 {*68k_extendhisi2} (nil)
(nil))
test.c:10: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:393
Appears to have been caused by r106804 (reverting this patch allows the build
to succeed):
2005-11-12 Hans-Peter Nilsson <[EMAIL PROTECTED]>
PR middle-end/24750
* reload.c (find_reloads_address_1) : New cases.
--
Summary: m68k build failure: ICE: in reload_cse_simplify_operands
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: hp at gcc dot gnu dot org
ReportedBy: pbrook at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m68k-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24912
[Bug rtl-optimization/24912] m68k build failure: ICE: in reload_cse_simplify_operands
--- Comment #1 from joel at gcc dot gnu dot org 2005-11-17 15:36 --- Also fails building m68k-rtems4.7. -- joel at gcc dot gnu dot org changed: What|Removed |Added CC||joel at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-17 15:36:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24912
[Bug rtl-optimization/24912] m68k build failure: ICE: in reload_cse_simplify_operands
--- Comment #2 from hp at gcc dot gnu dot org 2005-11-17 16:26 --- Confirmed with r107118. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24912
[Bug libobjc/24714] objc/execute/bf-10.m and others fail on sh64-elf
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-17 16:31 --- I think I understand why these fail. The issue comes down to PCC_BITFIELD_TYPE_MATTERS and ms style bitfields, we don't emulate them yet in libobjc with the new config directory should help fix this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|target |libobjc Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-17 16:31:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24714
[Bug target/24913] New: undocumented new CPU upgrade by -mpowerpc-gpopt overrides user-selected -mcpu= setting
The G4 PowerPC processor does not support the (full) GPOPT instruction
set that can be activated with -mpowerpc-gpopt. The documentation is not
explicitly clear on which (current) processors support this instruction set -
or any of the other additional/extended/optional sets like those selected with
-mpowerpc-gfxopt, -mstrings, -mmultiple, etc.
Earlier versions of gcc (until at least 4.0.0 4061) used to ignore
-mpowerpc-gpopt on the G4, judging from the assembly they produce (a simple
y=sqrt(x) statement is enough). Gcc 4.0.1 5301 has a new, undocumented
behaviour: it changes the target cpu to ppc970. The resulting code crashes on a
G4, of course. This happens even when the compiler was instructed to compile
for a G4, i.e. when invoked with -mcpu=G4 -mpowerpc-gpopt (the order is
irrelevant).
Environment:
System: Darwin Zygiella.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30
20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh
powerpc
host: powerpc-apple-darwin7
build: powerpc-apple-darwin7
target: powerpc-apple-darwin7
configured with: /Volumes/Debian/gcc/gcc401build/../gcc-401-5301/configure
--prefix=/usr/local/gnu/gcc/4.0.1 --enable-languages=c,c++,objc,obj-c++,f95
--build=powerpc-apple-darwin7 --host=powerpc-apple-darwin7
--target=powerpc-apple-darwin7
How-To-Repeat:
Invoked the compiler with -mpowerpc-gpopt on a simple source file like
the example below. On a G4, the resulting fsqrt instruction that is generated
for the sqrt expression will crash. This also happens when compiled with
-mcpu=G4 -mpowerpc-gpopt .
###
#include
#include
#include
main( int argc, char *argv[] )
{ double x, y, z;
long long a, b;
if( argc>= 2 ){
sscanf( argv[1], "%lf", &x );
sscanf( argv[2], "%lf", &y );
}
else{
x= drand48() * 10.0;
y= drand48() * 5.0;
}
if( y== 0.5 ){
z= sqrt(x);
}
else{
z= pow( x, y );
}
printf( "pow(%g,%g)=%g\n", x, y, z );
a= x;
b= y;
printf( "(long long)(%lld * %lld) = %lld\n", a, b, a*b );
exit(0);
}
###
--- Comment #1 from vsxo at hotmail dot com 2005-11-17 16:47 ---
Fix:
The workaround is not to give the instruction. There are several
solutions. The documentation should be made up to date in this aspect; *also*
for -mpowerpc-gfxopt -mnew-mnemonics -mstring -mmultiple -misel). A good
additional solution would be to output a warning or error when selecting
incompatible instruction sets and target cpus. (Rationale: -mcpu=G4 -mmmx also
gives an abortive error...)
Ideally, a warning would also be given when an option is selected that
cause the resulting code to (potentially) crash on the host CPU (this used to
be the case under Irix), (even) in the absence of a specific cpu selector.
--
Summary: undocumented new CPU upgrade by -mpowerpc-gpopt
overrides user-selected -mcpu= setting
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vsxo at hotmail dot com
GCC build triplet: powerpc-apple-darwin7
GCC host triplet: powerpc-apple-darwin7
GCC target triplet: powerpc-apple-darwin7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24913
[Bug target/24913] undocumented new CPU upgrade by -mpowerpc-gpopt overrides user-selected -mcpu= setting
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-17 16:56 --- This is not an undocemented behavior. First it is documented that later options should override the earlier ones. Second this is an expected change. Third you should have reported this to Apple first since you are using their compiler and their build numbers prove it. Thrid the reason for this change was to allow -mcpu=G4 -mno-altivec. Fourth it is not incompatible at all as -mcpu=G4 -mpowerpc-gpopt works as expected as -mpowerpc-gpopt adds to -mcpu=G4. -- 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=24913
[Bug c/24914] New: gcc fails when built with --with-cpu=ep9312 --with-fpu=maverick
When compiling gcc 4_0-branch with the --with-cpu=ep9312 and
--with-fpu=maverick options, gcc fails.
gcc was configured with:
--prefix=/usr --host=x86_64-pc-linux-gnu --target=armv4l-unknown-linux-gnu
--with-cpu=ep9312 --with-fpu=maverick --build=x86_64-pc-linux-gnu
--disable-altivec --disable-nls --with-system-zlib --disable-checking
--disable-werror --disable-libunwind-exceptions --disable-multilib
--disable-libgcj --enable-languages=c,c++ --enable-__cxa_atexit
--enable-clocale=gnu
This is the error:
/tmp/build/gcc/xgcc -B/tmp/build/gcc/ -B/usr/armv4l-unknown-linux-gnu/bin/
-B/usr/armv4l-unknown-linux-gnu/lib/ -isystem
/usr/armv4l-unknown-linux-gnu/include -isystem
/usr/armv4l-unknown-linux-gnu/sys-include -O2 -DIN_GCC -DCROSS_COMPILE -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -fomit-frame-pointer -fPIC -g0
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I.
-I. -I../../gcc-4_0-branch/gcc -I../../gcc-4_0-branch/gcc/.
-I../../gcc-4_0-branch/gcc/../include
-I../../gcc-4_0-branch/gcc/../libcpp/include -DL_muldc3 -fvisibility=hidden
-DHIDE_EXPORTS -c ../../gcc-4_0-branch/gcc/libgcc2.c -o libgcc/./_muldc3.o
../../gcc-4_0-branch/gcc/libgcc2.c: In function '__muldc3':
../../gcc-4_0-branch/gcc/libgcc2.c:1696: error: unable to find a register to
spill in class 'VFP_REGS'
../../gcc-4_0-branch/gcc/libgcc2.c:1696: error: this is the insn:
(insn:HI 105 128 103 7 (set (reg:SI 0 r0 [158])
(and:SI (subreg:SI (reg/v:DF 30 mv3 [orig:126 a ] [126]) 4)
(const_int -2147483648 [0x8000]))) 54
{*arm_andsi3_insn} (nil)
(expr_list:REG_DEAD (reg/v:DF 30 mv3 [orig:126 a ] [126])
(nil)))
../../gcc-4_0-branch/gcc/libgcc2.c:1696: confused by earlier errors, bailing
out
make[2]: *** [libgcc/./_muldc3.o] Error 1
make[2]: Leaving directory `/tmp/build/gcc'
make[1]: *** [libgcc.a] Error 2
make[1]: Leaving directory `/tmp/build/gcc'
make: *** [all-gcc] Error 2
When executing the last command with -v:
fantasy gcc # /tmp/build/gcc/xgcc -B/tmp/build/gcc/
-B/usr/armv4l-unknown-linux-gnu/bin/ -B/usr/armv4l-unknown-linux-gnu/lib/
-isystem /usr/armv4l-unknown-linux-gnu/include -isystem
/usr/armv4l-unknown-linux-gnu/sys-include -O2 -DIN_GCC -DCROSS_COMPILE -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -fomit-frame-pointer -fPIC -g0
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I.
-I. -I../../gcc-4_0-branch/gcc -I../../gcc-4_0-branch/gcc/.
-I../../gcc-4_0-branch/gcc/../include
-I../../gcc-4_0-branch/gcc/../libcpp/include -DL_muldc3 -fvisibility=hidden
-DHIDE_EXPORTS -c ../../gcc-4_0-branch/gcc/libgcc2.c -o libgcc/./_muldc3.o -v
Reading specs from /tmp/build/gcc/specs
Target: armv4l-unknown-linux-gnu
Configured with: ../gcc-4_0-branch/configure --prefix=/usr
--host=x86_64-pc-linux-gnu --target=armv4l-unknown-linux-gnu --with-cpu=ep9312
--with-fpu=maverick --build=x86_64-pc-linux-gnu --disable-altivec --disable-nls
--with-system-zlib --disable-checking --disable-werror
--disable-libunwind-exceptions --disable-multilib --disable-libgcj
--enable-languages=c,c++ --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.0.3 20051117 (prerelease)
/tmp/build/gcc/cc1 -quiet -v -I. -I. -I../../gcc-4_0-branch/gcc
-I../../gcc-4_0-branch/gcc/. -I../../gcc-4_0-branch/gcc/../include
-I../../gcc-4_0-branch/gcc/../libcpp/include -iprefix
/tmp/build/gcc/../lib/gcc/armv4l-unknown-linux-gnu/4.0.3/ -isystem
/tmp/build/gcc/include -DIN_GCC -DCROSS_COMPILE -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -DL_muldc3 -DHIDE_EXPORTS
-isystem /usr/armv4l-unknown-linux-gnu/include -isystem
/usr/armv4l-unknown-linux-gnu/sys-include -isystem ./include
../../gcc-4_0-branch/gcc/libgcc2.c -quiet -dumpbase libgcc2.c -mcpu=ep9312
-mfpu=maverick -auxbase-strip libgcc/./_muldc3.o -g0 -O2 -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-version -fomit-frame-pointer -fPIC -fvisibility=hidden -o /tmp/ccD3Xhs8.s
ignoring nonexistent directory "/usr/armv4l-unknown-linux-gnu/sys-include"
ignoring duplicate directory "./include"
ignoring nonexistent directory
"/tmp/build/gcc/../lib/gcc/armv4l-unknown-linux-gnu/4.0.3/include"
ignoring nonexistent directory
"/tmp/build/gcc/../lib/gcc/armv4l-unknown-linux-gnu/4.0.3/../../../../armv4l-unknown-linux-gnu/sys-include"
ignoring nonexistent directory
"/tmp/build/gcc/../lib/gcc/armv4l-unknown-linux-gnu/4.0.3/../../../../armv4l-unknown-linux-gnu/include"
ignoring nonexistent directory
"/usr/lib/gcc/armv4l-unknown-linux-gnu/4.0.3/include"
ignoring nonexistent directory
"/usr/lib/gcc/../../armv4l-unknown-linux-gnu/sys-include"
ignoring duplicate directory
"/usr/lib/gcc/../../armv4l-unknown-linux-gnu/include"
ignoring dupli
[Bug c/24914] gcc fails when built with --with-cpu=ep9312 --with-fpu=maverick
--- Comment #1 from nekkar at libero dot it 2005-11-17 17:12 --- Created an attachment (id=10264) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10264&action=view) Preprocessed source Just to be clear, the gcc-4_0-branch was updated today, after the last fix to bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24861 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24914
[Bug c++/16021] Tests for container swap specialisations FAIL in debug mode
--- Comment #12 from jason at gcc dot gnu dot org 2005-11-17 17:18 --- The testcase compiles fine if you add using namespace std; within namespace NS. I'm not sure whether or not this should be implied by the strong using. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16021
[Bug c++/24915] New: Overload errors generated without template instantiations for class member templates
template
struct is_int
{
static const bool value = false;
};
template <>
struct is_int
{
static const bool value = true;
};
template
struct enable_if
{};
template
struct enable_if
{ typedef T type; };
class test
{
public:
template
typename enable_if::value>::type func(T x)
{}
template
typename enable_if::value>::type func(T x)
{}
};
fails to compile on 4.0.2 with
t2.cpp:29: error: ‘template typename enable_if<(! is_int::value),
void>::type test::func(T)Â’ cannot be overloaded
t2.cpp:25: error: with ‘template typename enable_if::value,
void>::type test::func(T)Â’
fails to compile on 3.4.2 with
t2.cpp:30: error: `template typename enable_if<(! is_int::value),
void>::type test::func(T)' and `template typename enable_if<
is_int::value, void>::type test::func(T)' cannot be overloaded
However the same two functions will compile when not defined as part of a class
template
typename enable_if::value>::type func(T x)
{}
template
typename enable_if::value>::type func(T x)
{}
both msvc7.1 and Comeau 4.3.3 will accept it.
I don't think that this is duplicate of 15882.
The problem appears to be that syntax checking is catching this before SFINAE
has a chance to prune the overload set. At any rate there are not template
instantiations in the test case.
--
Summary: Overload errors generated without template
instantiations for class member templates
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nem3 at pitt dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24915
[Bug fortran/20244] internal compiler error: in fold_convert, at fold-const.c:2003
--- Comment #12 from dwarak dot rajagopal at amd dot com 2005-11-17 17:30 --- (In reply to comment #9) > (In reply to comment #8) > > I got the same ICE with one of the SPEC2006 candidate benchmarks on > > x86_64-linux-gnu. > > Was this before or after my fix for PR 18157 went in? Because this and that > bug had the same ICE but are really different bugs. > Tried with gcc version 4.0.1 20050630 (prerelease) (without the patch) and the current head (with the patch).I see the same ICE for both before and after your patch in "wrf"(spec 2006). Tried with gcc version 4.0.1 20050630 (prerelease) (without the patch) and the current head (with the patch). - Dwarak -- dwarak dot rajagopal at amd dot com changed: What|Removed |Added CC||dwarak dot rajagopal at amd ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20244
[Bug target/24914] gcc fails when built with --with-cpu=ep9312 --with-fpu=maverick
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|major Component|c |target Keywords||build, ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24914
[Bug c++/24915] [3.4/4.0/4.1 Regression] Overload errors generated without template instantiations for class member templates
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24915
[Bug libgcj/9250] runtime should only use non-visible locks
--- Comment #4 from mckinlay at redhat dot com 2005-11-17 17:38 --- I'm curious whether other Java implementations do this - my guess is no, since some of these locks are mandated by the spec (during class initialization, for example), so it seems that denial-of-service attacks would always be possible. Its my understanding that the Java security model is not really designed or intended to guard against DOS attacks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9250
[Bug preprocessor/24916] New: option -O undocumented in cpp docs
[forwarded from http://bugs.debian.org/339495] you can see[1] that cpp supports -O, -O[1-9], -Os options, and these options are meaningful (defining macros). but this is not documented in man page[2] and info[3]. [1] $ cpp -dM /dev/null | grep OPT $ cpp -dM -O /dev/null | grep OPT #define __OPTIMIZE__ 1 $ cpp -dM -Os /dev/null | grep OPT #define __OPTIMIZE__ 1 #define __OPTIMIZE_SIZE__ 1 $ cpp -dM -O2 /dev/null | grep OPT #define __OPTIMIZE__ 1 [2] /usr/share/man/man1/cpp-4.0.1.gz [3] /usr/share/info/cpp-4.0.info.gz -- Summary: option -O undocumented in cpp docs Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24916
[Bug rtl-optimization/24912] m68k build failure: ICE: in reload_cse_simplify_operands
--- Comment #3 from joel at gcc dot gnu dot org 2005-11-17 17:59 --- Created an attachment (id=10265) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10265&action=view) Preprocessed file that produces ICE This is the command line which produces the ICE. I changed -c to -E to produce the attached file. /home/joel/gcc-work/head/b-m68k-rtems4.7/./gcc/xgcc -B/home/joel/gcc-work/head/b-m68k-rtems4.7/./gcc/ -nostdinc -B/home/joel/gcc-work/head/b-m68k-rtems4.7/m68k-rtems4.7/newlib/ -isystem /home/joel/gcc-work/head/b-m68k-rtems4.7/m68k-rtems4.7/newlib/targ-include -isystem /home/joel/gcc-work/head/gcc-head-test/newlib/libc/include -B/home/joel/gcc-41-test//m68k-rtems4.7/bin/ -B/home/joel/gcc-41-test//m68k-rtems4.7/lib/ -isystem /home/joel/gcc-41-test//m68k-rtems4.7/include -isystem /home/joel/gcc-41-test//m68k-rtems4.7/sys-include -c -DHAVE_CONFIG_H -O2 -g -O2 -I. -I../../../gcc-head-test/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../../gcc-head-test/libiberty/regex.c -c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24912
[Bug c/24916] option -O undocumented in cpp docs
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-17 18:02 --- The C front-end defines these. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|preprocessor|c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24916
[Bug c/24916] option -O undocumented in cpp docs
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-17 18:03 --- They are documented: http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24916
[Bug c/24916] option -O undocumented in cpp docs
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-17 18:04 --- Since they are documented, I am going to close this as invalid. -- 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=24916
[Bug c/24916] option -O undocumented in cpp docs
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-17 18:05 --- And have been since 3.1: http://gcc.gnu.org/onlinedocs/gcc-3.1/cpp/Common-Predefined-Macros.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24916
[Bug c++/16021] Tests for container swap specialisations FAIL in debug mode
--- Comment #13 from jason at gcc dot gnu dot org 2005-11-17 18:14 --- It also works if NS is nested within std, as in the example in the GCC documentation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16021
[Bug c/24916] option -O undocumented in cpp docs
--- Comment #5 from debian-gcc at lists dot debian dot org 2005-11-17 18:26 --- (In reply to comment #2) > They are documented: > http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html the point of the bug submitter was to have them documented in cpp(1). Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24916
[Bug libfortran/21995] Problem using spread intrinsic
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2005-11-17 18:31 --- This bug is a duplicate of PR 24384, which is fixed on 4.1 but not on 4.1. See comment #3 in PR 24384 for details. *** This bug has been marked as a duplicate of 24384 *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21995
[Bug fortran/24384] SPREAD does not handle scalar sources.
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-11-17 18:31 --- *** Bug 21995 has been marked as a duplicate of this bug. *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||gcc-bugzilla at chatsubo dot ||lagged dot za dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24384
[Bug c/24916] option -O undocumented in cpp docs
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-17 18:33 --- (In reply to comment #5) > the point of the bug submitter was to have them documented in cpp(1). But they are documented in the info page: Predefined Macros * Standard Predefined Macros:: * Common Predefined Macros:: * System-specific Predefined Macros:: * C++ Named Operators:: Which is not what the submitted said. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24916
[Bug c/24916] option -O undocumented in cpp docs
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-17 18:34 --- (In reply to comment #6) > (In reply to comment #5) > > the point of the bug submitter was to have them documented in cpp(1). > But they are documented in the info page: I should point out the web page is generated via the same document that the info page is generated from. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24916
[Bug target/23356] FLT_EVAL_METHOD not defined on openbsd3.4
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2005-11-17 18:34 --- (In reply to comment #5) > As far as OpenBSD is concerned, this bug is not important: neither 3.7, > nor 3.8, nor -current are affected. Well, if nobody is interested in this, closing accordingly. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23356
[Bug libstdc++/24660] versioning weak symbols in libstdc++
--- Comment #7 from jason at gcc dot gnu dot org 2005-11-17 18:57 ---
Here's a reduced testcase:
namespace N { }
namespace std
{
using namespace N __attribute__ ((strong));
}
namespace N
{
using namespace std;
template
struct A
{
void f();
};
}
namespace std
{
template<>
struct A
{
void f() { }
};
}
This code, like the testcase for c++/16021, works fine if the implementation
namespace is nested within std. I'm thinking of enforcing that requirement in
parse_using_directive; that would allow us to avoid adding more special lookup
rules. Do you see any problem with that requirement?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660
[Bug libstdc++/24660] versioning weak symbols in libstdc++
--- Comment #8 from jason at gcc dot gnu dot org 2005-11-17 19:01 --- The nesting also means you don't need the reciprocal using-directive which you added to avoid the problem from 16021. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660
[Bug fortran/24917] New: Handling of hexadecimal constants in gfortran
Compilation of the following program TEST.f fails: PROGRAM HEX_TEST INTEGER(4) MASK MASK = 'c0'X END ~ $ gfortran -c TEST.f In file TEST.f:5 MASK = 'c0'X 1 Error: Unclassifiable statement at (1) whereas the following code compiles correctly: PROGRAM HEX_TEST INTEGER(4) MASK MASK = X'c0' END As stated in http://gcc.gnu.org/ml/fortran/2005-11/msg00382.html, the first version of the code is an extension which was supported in g77, therefore it should also be supported in gfortran. The compiler I used to test this is: ~ $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.0.2/configure --prefix=/home/iev/apps/gcc-4.0.2 --enable-languages=c,c++,f95 --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libgcj --disable-nls Thread model: posix gcc version 4.0.2 -- Summary: Handling of hexadecimal constants in gfortran Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: iev at hpclab dot ceid dot upatras dot gr GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24917
[Bug libfortran/24918] New: GFORTRAN input and carriage returns
-- Summary: GFORTRAN input and carriage returns Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ray at ultramarine dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24918
[Bug libfortran/24919] New: GFORTRAN input and carriage returns
When reading a "dos" file, gfortran returns two records for each line in the file: the real record and a null one. In other words it is treating the carriage return as a newline instead of the pair carriage return/newline as the newline. Here is an example: integer ios character buf*(50) c open(10,file='dos',iostat=ios) print *,' open ios ',ios 1000 read(10,'(a)',iostat=ios) buf if(ios .ne.0) go to 9000 print '(a,a,a)',' read <',buf,'>' go to 1000 c 9000 end -- Summary: GFORTRAN input and carriage returns Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ray at ultramarine dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24919
[Bug fortran/24921] New: iostat on read
-- Summary: iostat on read Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ray at ultramarine dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24921
[Bug rtl-optimization/24922] New: gcc -O2 removes important instruction for ASM
I found that when I compile this code with -O2:
#include
#define bit_swap(v, count, res) \
do {\
asm volatile ( \
"1: sarb %1\n" \
" rclb %0\n" \
" sarb %1\n" \
" rclb %0\n" \
" loop 1b\n" \
: "=a" (res)\
: "d" (v), "c" (count) \
); \
} while (0)
int main()
{
char u1, u2;
u1=0xA;
bit_swap(u1, 4, u2);
bit_swap(u2, 4, u1);
printf("u1=0x%x u2=0x%x\n", u1, u2);
}
, gcc removes loop counter cx register between the first bit_swap() and the
second bit_swap() statements, which results in the problem that the second
bit_swap() is running 2^32 loops instead of 4 loops also it corrupts a final
result in u1.
#gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++
--prefix=/home/dinar/tmp/gcc-i686-pc-linux-gnu/
Thread model: posix
gcc version 4.1.0 20051026 (experimental)
--
Summary: gcc -O2 removes important instruction for ASM
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gvaxon at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24922
[Bug fortran/24923] New: iostat on read
The following has a problem integer buf(200),ios buf(1) = -77 buf(2) = -77 open(10,file='cow',access='DIRECT',recl=100,iostat=ios) print *,' open ios ',ios read(10,rec=1,iostat=ios) buf print *,' read ios ',ios print *,' buf 1 2 ',buf(1),buf(2) end When executed it creates an empty file. When the first record is read, it returns iostat=0 and changes the first two integers. Iostat should not be zero because the read was not finished. -- Summary: iostat on read Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ray at ultramarine dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24923
[Bug rtl-optimization/24922] gcc -O2 removes important instruction for ASM
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-17 20:05 --- Count is already in ecx so why should GCC move again count to the ecx register. Your inline-asm does not tell GCC that ecx is touched which is why GCC is removing the move. -- 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=24922
[Bug fortran/24921] iostat on read
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-17 20:06 --- *** This bug has been marked as a duplicate of 24923 *** -- 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=24921
[Bug fortran/24923] iostat on read
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-17 20:06 --- *** Bug 24921 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24923
[Bug fortran/24923] iostat on read
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-17 20:10 --- Actually this has already been fixed for 4.0.3 at least: open ios0 read ios3 buf 1 2 -77 -77 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24923
[Bug libfortran/24918] GFORTRAN input and carriage returns
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-17 20:11 --- *** This bug has been marked as a duplicate of 24919 *** -- 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=24918
[Bug libfortran/24919] GFORTRAN input and carriage returns
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-17 20:11 --- *** Bug 24918 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24919
[Bug libfortran/24919] GFORTRAN input and carriage returns
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-17 20:13 --- First can you try 4.0.2 or a snapshot of 4.0.3? Second can you attach the dos file? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24919
[Bug fortran/24917] Handling of hexadecimal constants in gfortran
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-17 20:16 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||19292 nThis|| Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-17 20:16:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24917
[Bug c++/24924] New: front end and preprocessor pedantic_errors settings should agree
The C++ front end makes pedwarns into errors by default (unless -fpermissive). However, this only applies to front end pedwarns and not to preprocessor ones, as the preprocessor has its own pedantic_errors setting which is changed by an explicit -pedantic-errors option but doesn't default to 1 for C++ the way the global setting does. There should be a consistent pedantic_errors setting for both compiler and preprocessor pedwarns. Test: preprocess a testcase such as #if 1 #endif 1 and observe it gives a warning which becomes an error with -pedantic-errors, whereas by the principle followed by the C++ front end it should be an error which becomes a warning with -fpermissive. -- Summary: front end and preprocessor pedantic_errors settings should agree Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24924
[Bug c++/24924] front end and preprocessor pedantic_errors settings should agree
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-17 20:26 --- Confirmed. -- pinskia 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-17 20:26:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24924
[Bug libfortran/24919] GFORTRAN input and carriage returns
--- Comment #3 from ray at ultramarine dot com 2005-11-17 20:28 --- Subject: Re: GFORTRAN input and carriage returns On Thu, 17 Nov 2005, pinskia at gcc dot gnu dot org wrote: > > > --- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-17 20:13 > --- > First can you try 4.0.2 or a snapshot of 4.0.3? Second can you attach the dos > file? > > > -- > > pinskia at gcc dot gnu dot org changed: > >What|Removed |Added > > CC||pinskia at gcc dot gnu dot >||org > > Sorry, but there was no good way to do that with the form. --- Comment #4 from ray at ultramarine dot com 2005-11-17 20:28 --- Created an attachment (id=10268) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10268&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24919
[Bug libfortran/24919] GFORTRAN input and carriage returns
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-17 20:31 --- Confirmed on the mainline. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||19292 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-17 20:31:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24919
[Bug libstdc++/24660] versioning weak symbols in libstdc++
--- Comment #9 from gdr at integrable-solutions dot net 2005-11-17 20:46 --- Subject: Re: versioning weak symbols in libstdc++ "jason at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | This code, like the testcase for c++/16021, works fine if the implementation | namespace is nested within std. I'm thinking of enforcing that | requirement in parse_using_directive; that would allow us to avoid | adding more special lookup rules. Do you see any problem with that | requirement? I'm for minimal invasion in the name lookup rules; so if that takes care of issues raised by Benjamin, I'm all for it. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660
[Bug fortran/20811] gfortran include problem (regression from g77)
--- Comment #10 from andreast at gcc dot gnu dot org 2005-11-17 20:51 --- After this patch libgfortran fails to build on darwin-ppc. it does not find the selected_int_kind.inc in the libgfortran objdir when building libgfortran. (selected_int_kind.f90 compilation) Reverting the patch brings me to a successful libgfortran build. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20811
[Bug target/24914] gcc fails when built with --with-cpu=ep9312 --with-fpu=maverick
--- Comment #2 from rearnsha at gcc dot gnu dot org 2005-11-17 20:55 --- The compiler is trying to reload the Maverick register into a VFP register. But there are no VFP registers on the ep9312! Testing a fix. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-17 20:55:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24914
[Bug ada/22333] [4.1 Regression] ACATS FAIL c34007p c34007r c45282b spurious discriminant CONSTRAINT_ERROR
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2005-11-17 21:03 --- Subject: Bug 22333 Author: ebotcazou Date: Thu Nov 17 21:03:50 2005 New Revision: 107134 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107134 Log: PR ada/22333 * trans.c (gnat_gimplify_expr, case ADDR_EXPR): Always make a temporary if taking the address of something that is neither reference, declaration, or constant, since the gimplifier can't handle that case. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/trans.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22333
[Bug ada/22333] [4.1 Regression] ACATS FAIL c34007p c34007r c45282b spurious discriminant CONSTRAINT_ERROR
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2005-11-17 21:05 --- See http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01311.html -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22333
[Bug target/24913] undocumented new CPU upgrade by -mpowerpc-gpopt overrides user-selected -mcpu= setting
--- Comment #3 from vsxo at hotmail dot com 2005-11-17 21:06 --- > This is not an undocemented behavior. The documentation did not change since 4.0.0, yet the behaviour did. I wonder if the previous behaviour also was not undocumented? > First it is documented that later options should override the earlier ones. Exactly. Which is why I added explicitly that the order does not make a difference: this is in contradiction of the general behaviour. -mpowerpc-gpopt -mcpu=G4 also generates code that crashes on a G4. > Second this is an expected change. And your second argument by authority. > Third you should have reported this to Apple first since you are using their Possibly. I contacted an Apple gcc-team member off-list because of this, and he told me to submit a bug report against the documentation. He didn't tell me to use the radarweb. I was planning to submit the report there too. > Thrid the reason for this change was to allow -mcpu=G4 -mno-altivec. ?? > Fourth it is not incompatible at all as -mcpu=G4 -mpowerpc-gpopt works as > expected as -mpowerpc-gpopt adds to -mcpu=G4. No, *unless* you mean by this that current FSF releases do not generate crashing code with this combination. It changes the specified CPU to a different one because the G4 does not have the GPOPT. A G5 is not a G4 with some stuff added, it is a very different processor that happens to be backwards binary compatible. G5-specific code can and will crash on a G4. Try it if you don't believe it with the code I included, and I'm almost certain this will happen in FSF 4.0.1 (or even 4.0.2) too. You can compare this with -mpowerpc64 . Would you maintain that -mcpu=G4 -mpowerpc64 adds 64bit support for some hypothetical G4++ cpu? The manpage clearly states that the -mpowerpc64 is a part of the full PowerPC64 architecture. Most people will be aware that the G4 is not. I took time to report this, after being asked to do so by someone who must have seen this report too. I'm not pleased by the tone of your reaction, so I'm taking the liberty to reopen the bug to be sure this counter-reaction does not go unnoticed. -- vsxo at hotmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24913
[Bug target/24913] undocumented new CPU upgrade by -mpowerpc-gpopt overrides user-selected -mcpu= setting
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-17 21:08 --- And this is documented already: If you wish to set an individual option to a particular value, you may specify it after the -mcpu option, like `-mcpu=970 -mno-altivec'. -- 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=24913
[Bug target/24913] undocumented new CPU upgrade by -mpowerpc-gpopt overrides user-selected -mcpu= setting
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-17 21:10 --- That was from: http://gcc.gnu.org/onlinedocs/gcc/RS_002f6000-and-PowerPC-Options.html#RS_002f6000-and-PowerPC-Options And: http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/RS_002f6000-and-PowerPC-Options.html#RS_002f6000-and-PowerPC-Options And: http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/RS_002f6000-and-PowerPC-Options.html And: http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/RS_002f6000-and-PowerPC-Options.html Which means before we had a bug in that the behavior did not match the documented behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24913
[Bug middle-end/24900] [4.1 Regression] new "value computed is not used" warning in gcc 4.1
--- Comment #7 from aldyh at gcc dot gnu dot org 2005-11-17 21:12 --- We used to allow this, but have now made the warning stricter. This behavior was done deliberately. See: http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00275.html As is explained in the thread, you can modify the macro to use statement expressions and avoid the warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24900
[Bug middle-end/24900] [4.1 Regression] new "value computed is not used" warning in gcc 4.1
--- Comment #8 from aldyh at gcc dot gnu dot org 2005-11-17 21:15 --- See previous comment. -- aldyh at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24900
[Bug target/24913] undocumented new CPU upgrade by -mpowerpc-gpopt overrides user-selected -mcpu= setting
--- Comment #6 from vsxo at hotmail dot com 2005-11-17 21:26 --- Sure, sure. But -mcpu=970 -mno-altivec makes sense: it just causes the SIMD unit to be unused. -mcpu=G3 -maltivec does not make sense. I don't agree that it should be possible to override the explicitly selected architecture, WITHOUT WARNING or error. Imagine a compiler configured for a cross-compiling environment, as Apple's fat binaries. What do you do with -mcpu=pentium-m -mpowerpc-gpopt ? Output code for the G5 knowing full well the user just asked for pentium-m code? Ignore the incompatible specifier? The most sensical thing to do in this case is to give an error and abort. In reaction to the references: I don't see the bug. That is, I don't see how the earlier behaviour is incompatible with the documentation you refer to (which is given in the manpage too). To me it makes more sense to ignore an unsupported option than to 'upgrade' the selected target cpu and generate code that crashes. -mpowerpc64 is a bit different in this in that the manpage clearly mentions that is belongs to ppc64: a G4 clearly doesn't. There, I can't criticise (though a warning would still be preferrable). And I see this: "Specifying the -mcpu=cpu_type overrides the specification of these options. " This suggests rather explicitly that -mpowerpc-gpopt -mcpu=G4 should undo the selection of the GPOPT instruction set. The documentation is vague in that the G4 nor the G5 are mentioned among the Motorola and IBM processors listed in the description of these arguments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24913
[Bug fortran/20811] gfortran include problem (regression from g77)
--- Comment #11 from andreast at gcc dot gnu dot org 2005-11-17 21:30 --- Adding -I. to FC in the Makefile of libgfortran makes my compile happy again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20811
[Bug c++/24926] New: gcc ignores access level violation: struct variables in anonymous union accessible as public
When declaring an anonymous union inside a class,
any variable from an anonymous struct contained in the union is accessible
like a public member, regardless of the access level of the enclosing union.
Bug does only occur when struct and union are BOTH anonymous.
The following sample code, which violates access level, compiles under gcc
3.3.6, 3.4.5 debian prerelease and gcc 4.0.2.
Expected result: gcc should report access level violation.
testcase
class foo {
private:
union {
struct {
int should_be_private;
};
};
};
int main()
{
foo test;
test.should_be_private = 1;
}
--
Summary: gcc ignores access level violation: struct variables in
anonymous union accessible as public
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at warped-space dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24926
[Bug target/24913] undocumented new CPU upgrade by -mpowerpc-gpopt overrides user-selected -mcpu= setting
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-17 21:43 --- (In reply to comment #6) > The documentation is vague in that the G4 nor the G5 are mentioned among the > Motorola and IBM processors listed in the description of these arguments. That is because G4 and G5 are marketing names from Apple and nobody else. Think of -mcpu=XXX as a meta flag for -mtune=XXX and all the options implied it. And order does not matter where it comes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24913
[Bug c++/24926] gcc ignores access level violation for anonymous structs
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-17 21:48 --- Confirmed, I should note that anonymous structs are extensions. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-17 21:48:33 date|| Summary|gcc ignores access level|gcc ignores access level |violation: struct variables |violation for anonymous |in anonymous union |structs |accessible as public| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24926
[Bug target/24913] undocumented new CPU upgrade by -mpowerpc-gpopt overrides user-selected -mcpu= setting
--- Comment #8 from vsxo at hotmail dot com 2005-11-17 21:52 --- Of course, G4 and G5 are marketing names for *FreeScale* 74xx and IBM ppc970xx cpus respectively. These are listed under the values that can be given to -mcpu et al, but I can't find them in the list of cpus given under -mpowerpc-gpopt et al. > And order does not matter where it comes. I give up. Are you contradicting what you just said earlier? In that case the phrase I cited in #6 is wrong! Gcc has so many convenience/t options that warn the programmer for doing unwise things. Why not add a warning (or error) when requesting impossible cpu features, or ones that are not available on the current host cpu? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24913
[Bug libstdc++/24660] versioning weak symbols in libstdc++
--- Comment #10 from bkoz at gcc dot gnu dot org 2005-11-17 21:53 --- Created an attachment (id=10271) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10271&action=view) Kona paper, as revised but not in post-Kona mailing -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660
[Bug libstdc++/24660] versioning weak symbols in libstdc++
--- Comment #11 from bkoz at gcc dot gnu dot org 2005-11-17 21:54 --- Created an attachment (id=10272) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10272&action=view) Outline for Kona presentation I cannot believe I found this stuff. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660
[Bug libfortran/24927] New: libfortran isn't parallel build safe
Makefile in libgfortran has selected_int_kind.lo: intrinsics/selected_int_kind.f90 $(LIBTOOL) --mode=compile $(FC) $(AM_FCFLAGS) $(FCFLAGS) -c -o selected_int_kind.lo `test -f 'intrinsics/selected_int_kind.f90' || echo '$(srcdir)/'`intrinsics/selected_int_kind.f90 But it doesn't depend on selected_int_kind.inc. With "make -j 4", I got /export/build/gnu/gcc/build-ia64-linux/./gcc/gfortran -B/export/build/gnu/gcc/build-ia64-linux/./gcc -B/usr/gcc-4.1/ia64-unknown-linux-gnu/bin/ -B/usr/gcc-4.1/ia64-unknown-linux-gnu/lib/ -isystem /usr/gcc-4.1/ia64-unknown-linux-gnu/include -isystem /usr/gcc-4.1/ia64-unknown-linux-gnu/sys-include -Wall -fno-repack-arrays -fno-underscoring -g -O2 -c /net/gnu-13/export/gnu/src/gcc/gcc/libgfortran/intrinsics/selected_int_kind.f90 -fPIC -DPIC -o .libs/selected_int_kind.o checking pwd.h presence... Error: Can't open included file 'selected_int_kind.inc' In file /net/gnu-13/export/gnu/src/gcc/gcc/libgfortran/intrinsics/selected_int_kind.f90:36 In file /net/gnu-13/export/gnu/src/gcc/gcc/libgfortran/intrinsics/selected_int_kind.f90:37 In file /net/gnu-13/export/gnu/src/gcc/gcc/libgfortran/intrinsics/selected_int_kind.f90:39 In file /net/gnu-13/export/gnu/src/gcc/gcc/libgfortran/intrinsics/selected_int_kind.f90:35 selected_real_kind.lo has the same problem and I suspect there are more than those 2. -- Summary: libfortran isn't parallel build safe Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24927
[Bug libstdc++/24660] versioning weak symbols in libstdc++
--- Comment #12 from bkoz at gcc dot gnu dot org 2005-11-17 22:15 ---
Here you go Jason. Actually, it looks like I have a complete archive of most
parts of this discussion, the related material, code samples, issues, etc. If
you would like, I will tar it up and put it in this pr. Or, if you are
interested, I can send it to you (or others) via private email.
I should have just put this stuff in post-Kona: sorry. I need to get better
about this kind of thing.
Anyway. Jason, I think making the namespace nested is fine. Interestingly, I
reviewed these discussions, and it looks like at the time of the debug mode
design discussion, we were wondering about the pros and cons of nested vs.
separate namespaces.
Looks like now we know more about these tradeoffs.
The only drawback that I can see is trying to reduce the size penalty for
mangled names. This is going to be an issue for some people, and we might as
well admit it from the start.
I'd thought of nested solutions, including the obvious ones:
namespace _6 {
namespace std {
namespace std {
namespace _6 {
but the problem is then that all the specialized compression for narrow std::
types (basic_string, basic_istream, etc) will fall down, and all your names go
through two namespace manglings. I'm not convinced this is such a bad thing,
actually: having non-compressed std:: would mean post-processing of library
binaries with other tools will become much more regular, without substitutions.
Of course,
namespace _6 {
also removes the specialized namespace std:: compression, but the fully
qualified name is still within reasonable limits of the current status quo.
This was judged to be the least obese of all options, in terms of symbol size
explosion. (ie _ZNS vs. _ZN2_6).
I must tell you that I would rather have this feature (and a resolution to the
weak symbol vs. shared object problem), and loose compression, than have either
the benefits of compression or a shorter fully qualified name. If I had a magic
wand, of course, I'd pick compression on generic template type name, not
instance name, so that wchar_t and char types would also be compressed
(ie compress basic_string, not basic_string), plus namespace association.
That might be a way to win back some of the loss if we switch to something like
std::_6 for the namespace.
Anyway.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660
