[Bug rtl-optimization/15792] missed subreg optimization
--- Comment #9 from ian at airs dot com 2006-02-07 08:23 --- I now have a reasonably simple reload patch which eliminates the unnecessary move. For the test case in comment #4, I get this code with -O2 -momit-leaf-frame-pointer: foo: movl12(%esp), %eax movl16(%esp), %edx addl4(%esp), %eax adcl8(%esp), %edx orl %eax, %edx jne .L7 rep ; ret .p2align 4,,7 .L7: jmp gh -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15792
[Bug rtl-optimization/23812] swapping DImode halves produces poor x86 register allocation
--- Comment #4 from ian at airs dot com 2006-02-07 08:31 --- With my current set of subreg patches, for this test case with -O2 -momit-leaf-frame-pointer, I get this: foo: movl4(%esp), %edx movl8(%esp), %eax ret which I suspect is optimal. -- ian at airs dot com changed: What|Removed |Added CC||ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23812
[Bug fortran/26150] New: Initialize local scalar variables
It would be nice having a compile-time option to initialize local scalar variables, to zero (.false. for logical, 0 for integer and 0.0 for real) and to NaN (for floating-point types). g77 had -finit-local-zero, Intel has -zero, we could have -finit-local-zero and -finit-local-nan. -- Summary: Initialize local scalar variables Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26150
[Bug fortran/26150] Initialize local scalar variables
-- 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 |2006-02-07 09:06:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26150
[Bug middle-end/22156] [4.0/4.1/4.2 Regression] bit-field copying regressed
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-02-07 09:26 --- Steven, if we increased the priority of the bug, what solution would you envision? This is not in any way meant to be a rhetorical or sarcastic question. My reading of the audit trail is that this bug is essentially a feature request for a new optimization; given that, I don't think we can make it release-critical. Am I misunderstanding? Thanks, -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22156
[Bug c++/26151] New: [3.4/4.0/4.1/4.2 regression] duplicate 'duplicate' diagnostic
GCC produces a duplicate 'duplicate' diagnostic ;-) since GCC 3.4.0
for the following testcase:
struct A
{
friend friend void foo();
};
bug.cc:3: error: duplicate 'friend'
bug.cc:3: error: duplicate 'friend'
I'll post a patch soon.
--
Summary: [3.4/4.0/4.1/4.2 regression] duplicate 'duplicate'
diagnostic
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: diagnostic, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26151
[Bug target/22097] libgfortran build failure on mips-sgi-irix6.5
--- Comment #15 from r dot emrich at de dot tecosim dot com 2006-02-07 09:55 --- Created an attachment (id=10794) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10794action=view) fixes bootstrap failure in ligfortran/instrisics/c99_functions.c for mips-sgi-irix6.5 It's similiar as http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01578.html There is one open question. Is the #ifdef __sgi__ the right way to distinguish between IRIX and other mips systems? This patch applies cleanly to 4.1 and mainline. I ask for comments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22097
[Bug c++/26151] [3.4/4.0/4.1/4.2 regression] duplicate 'duplicate' diagnostic
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-07 09:56:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26151
[Bug target/22097] libgfortran build failure on mips-sgi-irix6.5
--- Comment #16 from r dot emrich at de dot tecosim dot com 2006-02-07 10:00 --- (In reply to comment #15) Created an attachment (id=10794) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10794action=view) [edit] fixes bootstrap failure in ligfortran/instrisics/c99_functions.c for mips-sgi-irix6.5 It's similiar as http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01578.html There is one open question. Is the #ifdef __sgi__ the right way to distinguish between IRIX and other mips systems? This patch applies cleanly to 4.1 and mainline. I ask for comments. additional information: This patch applied, bootstrap finished successfully for 4.1 svn revision 110639. Testsuite in progress. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22097
[Bug c++/26140] [4.2 Regression] ice on valid C++ code
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-02-07 10:07 --- Ho humm, so I propose to revert the patch (that I didn't like very much anyway). Can I do so without approval? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26140
[Bug target/22097] libgfortran build failure on mips-sgi-irix6.5
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2006-02-07 10:12 --- (In reply to comment #15) There is one open question. Is the #ifdef __sgi__ the right way to distinguish between IRIX and other mips systems? This patch applies cleanly to 4.1 and mainline. I ask for comments. Looking at config.guess and other occurences of __sgi__ in the gcc source, I think it's the right way. Submit the patch on the gcc, gcc-patches and fortran along with the question, and if there is no objection from the mips maintainers in the next few days, I'll approve it. Thanks for the patch! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22097
[Bug c++/26084] [gomp-branch] ICE (segfault) on C++ OpenMP code
--- Comment #5 from martin at mpa-garching dot mpg dot de 2006-02-07 10:44 --- (In reply to comment #4) I still get the segmentation fault. Probably because I configured with --enable-checking=release... I can confirm that I get the same error message reported Volker if I boostrap gcc without --enable-checking=release. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26084
[Bug java/26152] New: gtkImage.c complains and crashes the application
ImageJ, the public domain scientific-grade image processing application
compiles fine with the gcj-wrapper-4.0 in Kubuntu GNU/Linux-ppc when stripped
of JPEG functionality and its dependance on the tools.jar. But when trying to
open an image, the gtkImage.c file complains:
** ERROR **: file
../../../src/libjava/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkImage.c: line 572
(createRawData): assertion failed: (data_fid != 0)
aborting...
I attach a self-contained test case below. Here are the commands to compile and
run it:
$ /usr/bin/gcj-wrapper-4.0 -g testGtkImage.java
$ /usr/lib/jvm/java-gcj/bin/java testGtkImage
The JFileChooser never shows. Here's the error message:
** ERROR **: file
../../../src/libjava/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkImage.c: line 572
(createRawData): assertion failed: (data_fid != 0)
aborting...
Aborted
/* START TEST CASE /
import java.awt.Canvas;
import java.awt.FileDialog;
import java.awt.Frame;
import java.io.File;
import javax.swing.SwingUtilities;
import javax.swing.JFileChooser;
public class testGtkImage {
String omDirectory;
File[] omFiles;
testGtkImage() {
final Frame frame = new Frame(testGtkImage);
Canvas canvas = new Canvas();
canvas.setSize(400, 200);
frame.add(canvas);
frame.setSize(400, 200);
frame.pack();
frame.show();
// test FileDialog
FileDialog fd = new FileDialog(frame, Select file,
FileDialog.LOAD);
fd.show();
System.out.println(fd.getDirectory() + + fd.getFile());
// NO PROBLEM with FileDialog
// test JFileChooser as in ij.io.Opener.openMultiple()
try {
SwingUtilities.invokeAndWait(new Runnable() {
public void run() {
JFileChooser fc = new JFileChooser();
fc.setMultiSelectionEnabled(true);
File dir = null;
String sdir = /home/; //
OpenDialog.getDefaultDirectory();
if (sdir!=null)
dir = new File(sdir);
if (dir!=null)
fc.setCurrentDirectory(dir);
int returnVal =
fc.showOpenDialog(frame);
if
(returnVal!=JFileChooser.APPROVE_OPTION)
return;
omFiles = fc.getSelectedFiles();
if (omFiles.length==0) { //
getSelectedFiles does not work on some JVMs
omFiles = new File[1];
omFiles[0] =
fc.getSelectedFile();
}
omDirectory =
fc.getCurrentDirectory().getPath()+File.separator;
}
});
} catch (Exception e) {}
if (omDirectory==null) return;
//OpenDialog.setDefaultDirectory(omDirectory);
for (int i=0; iomFiles.length; i++) {
String path = omDirectory + omFiles[i].getName();
System.out.println(Path: + path);
//open(path);
/*
if (i==0 Recorder.record)
Recorder.recordPath(open, path);
if (i==0 !error)
Menus.addOpenRecentItem(path);
*/
}
}
static public void main(String[] args) {
new testGtkImage();
}
}
/*** EOF /
--
Summary: gtkImage.c complains and crashes the application
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cardona at ucla dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26152
[Bug c++/9737] [DR150] Partial template specialisation selection failure involving template parameter defaults
--- Comment #22 from mmitchel at gcc dot gnu dot org 2006-02-07 11:11 --- Subject: Bug 9737 Author: mmitchel Date: Tue Feb 7 11:11:30 2006 New Revision: 110693 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110693 Log: PR c++/9737 * pt.c (coerce_template_template_parms): Do not templates with excess default arguments to match template template parameters with fewer parameters. (coerce_template_parms): Add use_default_args parameter; use default arguments only when true. (lookup_template_class): Adjust call to coerce_template_parms. (fn_type_unification): Likewise. (unify): Likewise. (get_bindings): Likewise. (dependent_type_p): Add assertions. PR c++/9737 * g++.dg/template/ttp15.C: New test. * g++.dg/template/ttp16.C: Likewise. * g++.dg/template/ttp17.C: Likewise. * g++.old-deja/g++.pt/ttp36.C: Remove. * g++.old-deja/g++.pt/ttp19.C: Likewise. * g++.old-deja/g++.pt/ttp37.C: Likewise. * g++.old-deja/g++.pt/ttp38.C: Likewise. * g++.old-deja/g++.pt/ttp39.C: Likewise. * g++.old-deja/g++.pt/ttp9.C: Likewise. * g++.old-deja/g++.pt/ttp40.C: Likewise. * g++.old-deja/g++.pt/ttp51.C: Likewise. * g++.old-deja/g++.pt/ttp26.C: Likewise. * g++.old-deja/g++.pt/ttp36.C: Likewise. * testsuite/testsuite_tr1.h (test_property): New function. * testsuite/tr1/4_metaprogramming/type_properties/extent/extent.cc (test01) Added: trunk/gcc/testsuite/g++.dg/template/ttp15.C trunk/gcc/testsuite/g++.dg/template/ttp16.C trunk/gcc/testsuite/g++.dg/template/ttp17.C Removed: trunk/gcc/testsuite/g++.old-deja/g++.pt/ttp19.C trunk/gcc/testsuite/g++.old-deja/g++.pt/ttp26.C trunk/gcc/testsuite/g++.old-deja/g++.pt/ttp35.C trunk/gcc/testsuite/g++.old-deja/g++.pt/ttp36.C trunk/gcc/testsuite/g++.old-deja/g++.pt/ttp37.C trunk/gcc/testsuite/g++.old-deja/g++.pt/ttp38.C trunk/gcc/testsuite/g++.old-deja/g++.pt/ttp39.C trunk/gcc/testsuite/g++.old-deja/g++.pt/ttp40.C trunk/gcc/testsuite/g++.old-deja/g++.pt/ttp51.C trunk/gcc/testsuite/g++.old-deja/g++.pt/ttp9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/testsuite_tr1.h trunk/libstdc++-v3/testsuite/tr1/4_metaprogramming/type_properties/extent/extent.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9737
[Bug c++/9737] [DR150] Partial template specialisation selection failure involving template parameter defaults
--- Comment #23 from mmitchel at gcc dot gnu dot org 2006-02-07 11:14 --- Fixed in G++ 4.2. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9737
[Bug bootstrap/25842] Error in building libiberty
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-02-07 11:20 --- OK, I understand why this is happenning only to me (it happened today on mips-sgi-irix6.5). I usually configure with CC=/path/to/gcc -I/path/to/gmp_includes -L/path/to/gmp_libs ../gcc/configure and then, I happened to have an ansidecl.h in /path/to/gmp_includes. I don't think this kind of configuration is supported, if it is not, please close this bug as INVALID. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25842
[Bug java/26152] gtkImage.c complains and crashes the application
--- Comment #1 from konqueror at gmx dot de 2006-02-07 11:23 --- Subject: Re: New: gtkImage.c complains and crashes the application On Tue, Feb 07, 2006 at 11:10:20AM -, cardona at ucla dot edu wrote: ImageJ, the public domain scientific-grade image processing application compiles fine with the gcj-wrapper-4.0 in Kubuntu GNU/Linux-ppc when stripped of JPEG functionality and its dependance on the tools.jar. But when trying to open an image, the gtkImage.c file complains: ** ERROR **: file ../../../src/libjava/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkImage.c: line 572 (createRawData): assertion failed: (data_fid != 0) aborting... This is a Debian-specific bug in gcj-4.0. We patch the upstream sources but the patch we use is somehow broken. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=335650 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=314704 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=324502 Unfortunately I was not able to fix this bug yet. Cheers, Michael -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26152
[Bug libstdc++/26153] New: incorrect namespace for C standard library headers.
the c++ versions of the c library header files provided with
the gcc don't put the c standard library names into the std namespace
as specified by the $17.4.1.2/4.
#include cstdio
int main() { printf(Hi\n); }
sunstudio11 rejects this code, g++ accepts.
--
Summary: incorrect namespace for C standard library headers.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC build triplet: *-linux
GCC host triplet: *-linux
GCC target triplet: *-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26153
[Bug bootstrap/26050] [4.2 Regression] Use of u_int32_t in libgcc-math breaks bootstrap on Solaris 10/x86
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-02-07 11:37 --- Subject: Bug 26050 Author: rguenth Date: Tue Feb 7 11:37:15 2006 New Revision: 110694 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110694 Log: 2006-02-07 Richard Guenther [EMAIL PROTECTED] PR bootstrap/26050 * configure.ac: Generate gstdint.h using GCC_HEADER_STDINT. * configure: Re-generate. * Makefile.in: Likewise. * aclocal.m4: Likewise. * i386/Makefile.am: Adjust include path. * i386/Makefile.in: Re-generate. * include/math_private.h: Do not include sys/types.h. Include gstdint.h. Use uint32_t instead of u_int32_t. * flt-32/e_expf.c: Do not include inttypes.h * flt-32/e_sqrtf.c: Use uint32_t instead of u_int32_t. * flt-32/s_floorf.c: Likewise. * flt-32/e_atan2f.c: Likewise. * flt-32/e_powf.c: Likewise. * flt-32/e_rem_pio2f.c: Likewise. * flt-32/e_log10f.c: Likewise. * dbl-64/s_floor.c: Likewise. * dbl-64/e_log10.c: Likewise. * dbl-64/e_rem_pio2.c: Likewise. Modified: trunk/libgcc-math/ChangeLog trunk/libgcc-math/Makefile.in trunk/libgcc-math/aclocal.m4 trunk/libgcc-math/configure trunk/libgcc-math/configure.ac trunk/libgcc-math/dbl-64/e_log10.c trunk/libgcc-math/dbl-64/e_rem_pio2.c trunk/libgcc-math/dbl-64/s_floor.c trunk/libgcc-math/flt-32/e_atan2f.c trunk/libgcc-math/flt-32/e_expf.c trunk/libgcc-math/flt-32/e_log10f.c trunk/libgcc-math/flt-32/e_powf.c trunk/libgcc-math/flt-32/e_rem_pio2f.c trunk/libgcc-math/flt-32/e_sqrtf.c trunk/libgcc-math/flt-32/s_floorf.c trunk/libgcc-math/i386/Makefile.am trunk/libgcc-math/i386/Makefile.in trunk/libgcc-math/include/math_private.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26050
[Bug java/26152] gtkImage.c complains and crashes the application
--- Comment #2 from cardona at ucla dot edu 2006-02-07 11:55 --- So there is no known patch for this bug then. Are there any plans to tackle the problem? I understand it cripples lots of applications. Thanks for looking at the bug report. Albert -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26152
[Bug java/26152] gtkImage.c complains and crashes the application
--- Comment #3 from konqueror at gmx dot de 2006-02-07 12:05 --- Subject: Re: gtkImage.c complains and crashes the application On Tue, Feb 07, 2006 at 11:55:10AM -, cardona at ucla dot edu wrote: --- Comment #2 from cardona at ucla dot edu 2006-02-07 11:55 --- So there is no known patch for this bug then. Are there any plans to tackle the problem? I understand it cripples lots of applications. Thanks for looking at the bug report. In Debian we dont care much about it anymore as soon gcc-4.1 will be released and the gcj included not have this problem. When its out we will remove gcj-4.0 from debian unstable and more to gcj-4.1. Cheers, Michael -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26152
[Bug c++/26084] [gomp-branch] ICE (segfault) on C++ OpenMP code
--- Comment #6 from dnovillo at gcc dot gnu dot org 2006-02-07 12:12 --- Mine. -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-07 12:12:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26084
[Bug fortran/26150] Initialize local scalar variables
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-07 12:37 --- Isn't this is a dup of bug 20441? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26150
[Bug libstdc++/26153] incorrect namespace for C standard library headers.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-07 12:41 --- This is a dup of bug 6257 (and there was some talk about this recently on the mailing list that it might actually be ok that libstdc++ does this but I am not sure). *** This bug has been marked as a duplicate of 6257 *** -- 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=26153
[Bug libstdc++/6257] C-library symbols enter global namespace
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-02-07 12:41 --- *** Bug 26153 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
[Bug java/26152] gtkImage.c complains and crashes the application
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-07 12:42 --- Closing as works for me since this bug does not effect the FSF released GCC. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26152
[Bug fortran/20441] -finit-local-zero is missing from gfortran
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-02-07 12:48 --- *** Bug 26150 has been marked as a duplicate of this bug. *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20441
[Bug fortran/26150] Initialize local scalar variables
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-02-07 12:48 --- Yes, it's a duplicate of 20441 (which I didn't know about). Although I don't understand your comment in PR20441 about -finit-local-zero being only useful for old codes. *** This bug has been marked as a duplicate of 20441 *** -- 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=26150
[Bug libstdc++/26123] [3.4/4.0 Regression] Segmentation fault in constructor of std::ostream::sentry::sentry
--- Comment #9 from broeni at osb-systems dot com 2006-02-07 12:52 ---
Obviously the behavior of the test program is undefined.
The following is the reply from Alberto Ganesh Barbati in c.l.c++.m
Apart from the fact that you need to include ostream in order to be
able to write on std::cout, yes: it's well defined. However, its
behaviour is unspecified. See below.
In particular: Does the standard guarantee that std::cout is
initialized before the constant `cInt'?
No, the standard does not guarantee that (although it non-normatively
encourages implementations to do it). According to ยง27.3/2: The objects
[std::cin, std::cout, etc.] are constructed, and the associations are
established at some time prior to or during first time an object of
class ios_base::Init is constructed, and in any case before the body of
main begins execution.
So in order to ensure that the program behave as expected, you need to
construct a variable of type ios_base::Init before using std::cout. You
can either use a global variable like this:
int mkCint();
std::ios_base::Init gInitIostreams;
const int cInt = mkCint();
or use a local variable in function mkCint():
int mkCint()
{
static std::ios_base::Init initIostreams;
std::cout mkCint() std::endl;
return 2;
}
Comment:
While the use of a global variable works fine for the reduced test #2 the
originally posted code (#1) only works with a local std::ios_base::Init in
mkCint() because of the undefined initialization order of globals.
The reply of James Kanze confirms the undefined behavior:
Is the following program well defined?
In particular: Does the standard guarantee that std::cout is
initialized before the constant `cInt'?
No.
With the classical implementation of iostream.h, it was
guaranteed IF your code included iostream.h before defining
cInt. Many (most?, all?) current implementations of iostream
also provide this guarantee, but the standard doesn't require
it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26123
[Bug target/22209] [4.1/4.2 regression] libgfortran unresolvable symbols on irix6.5
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-02-07 12:59 --- How hard is it to add the TI mode functions? Is it specific to IRIX, or does it happen (as I believe) on mips-linux as well? And are the maintainers ready to do it? I'm adding mips maintainers in the Cc list. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||rsandifo at gcc dot gnu dot ||org, echristo at gcc dot gnu ||dot org Last reconfirmed|2006-01-12 22:09:07 |2006-02-07 12:59:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22209
[Bug libstdc++/26123] [3.4/4.0 Regression] Segmentation fault in constructor of std::ostream::sentry::sentry
--- Comment #10 from broeni at osb-systems dot com 2006-02-07 13:19 --- See comment #9 for reason. Stephan -- broeni at osb-systems dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26123
[Bug target/22209] [4.1/4.2 regression] libgfortran unresolvable symbols on irix6.5
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-07 13:32 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00409.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||02/msg00409.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22209
[Bug bootstrap/25842] Error in building libiberty
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-07 13:36 --- No this is not supported as you force gmp's header first no matter what. Use either -idirafter or the folllowing configure options: --with-gmp-dir=PATH Specify source directory for GMP library --with-gmp=PATH Specify directory for installed GMP library -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25842
[Bug c/26154] New: OpenMP extensions to the C language is not documented
I noticed that the OpenMP extensions are not documented in the normal spot for extensions in the Extensions to the C Language Family in the manual. This is wrong as they are extensions we support to the C standard. -- Summary: OpenMP extensions to the C language is not documented Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: documentation, openmp Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26154
[Bug c/26154] [4.2 Regression] OpenMP extensions to the C language is not documented
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-07 13:44 --- This is a regression as the document is out of date now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org Summary|OpenMP extensions to the C |[4.2 Regression] OpenMP |language is not documented |extensions to the C language ||is not documented Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26154
[Bug libstdc++/26123] [3.4/4.0 Regression] Segmentation fault in constructor of std::ostream::sentry::sentry
--- Comment #11 from pcarlini at suse dot de 2006-02-07 13:59 --- Thanks a lot for the torough clarification! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26123
[Bug c++/26151] [3.4/4.0/4.1/4.2 regression] duplicate 'duplicate' diagnostic
-- 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=26151
[Bug fortran/26150] Initialize local scalar variables
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-07 14:18 --- (In reply to comment #2) Although I don't understand your comment in PR20441 about -finit-local-zero being only useful for old codes. Because From what I remember whne I filed the bug, it was mentioned that it should be used only with old code (then again it was a while back). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26150
[Bug libstdc++/26142] global debug namespace clashes everywhere
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-07 14:20 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-07 14:20:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26142
[Bug c++/7876] g++ doesn't diagnose One Reference Rule violation
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-07 14:33 ---
I am going to reopen this one as we diagnostic the non template version:
struct X { };
struct B { };
struct A {
typedef X X;
};
But I am going to change the Severity to enhancement.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Status|RESOLVED|REOPENED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7876
[Bug c++/7876] g++ doesn't diagnose One Reference Rule violation
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7876
[Bug c++/4003] ICE on template instantiation including friendship declaration.
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |3.1.x/3.2.x http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4003
[Bug c++/5564] g++-3.0.3 infinite loop
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |3.1.x/3.2.x http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5564
[Bug c++/7363] bogus __alignof__ implementation
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |3.1.x/3.2.x http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7363
[Bug c++/26140] [4.2 Regression] ice on valid C++ code
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-07 14:46 --- (In reply to comment #5) Ho humm, so I propose to revert the patch (that I didn't like very much anyway). Can I do so without approval? Yes but what about fixing the C++ front-end so that it does not place the TARGET_EXPR in the wrong spot? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26140
[Bug c++/26155] New: ICE after error with namespace alias
I thought this was filed before but I cannot find it.
Testcase:
namespace std
{
namespace __gnu_debug {
namespace debug = std::__gnu_debug;
namespace debug
{
-
Error we get:
t.ii:6: error: namespace alias ยstd::__gnu_debug::debugย not allowed here,
assuming ยstd::__gnu_debugย
t.ii:6: internal compiler error: in resume_scope, at cp/name-lookup.c:1372
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ICE after error with namespace alias
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26155
[Bug libstdc++/26142] global debug namespace clashes everywhere
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-07 14:49 ---
(In reply to comment #1)
In fact this cause us to produce an error and an ICE for the following code:
#include iostream
namespace debug
{
int i;
}
--
t.cc:4: error: namespace alias ยdebugย not allowed here, assuming
ยstd::__gnu_debugย
t.cc:4: internal compiler error: in resume_scope, at cp/name-lookup.c:1372
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
The ICE should be filed as a seperate bug.
I filed that as PR 26155.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26142
[Bug java/26152] gtkImage.c complains and crashes the application
--- Comment #5 from cardona at ucla dot edu 2006-02-07 15:08 --- Before the end of this, are there any docs on how to compile the latest stable GCC, so that I can bypass this bug? The gcc-java webpage is very confusing; I don't even know if gcc-java can be compiled independently, or I need to compile the whole GCC, or what! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26152
[Bug libstdc++/26127] tr1/hashtable compile errors
--- Comment #2 from paolo at gcc dot gnu dot org 2006-02-07 15:11 --- Subject: Bug 26127 Author: paolo Date: Tue Feb 7 15:11:10 2006 New Revision: 110697 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110697 Log: 2006-02-07 Paolo Carlini [EMAIL PROTECTED] * include/tr1/hashtable: Trivial formatting fixes. 2006-02-07 Paolo Carlini [EMAIL PROTECTED] Zak Kipling [EMAIL PROTECTED] PR libstdc++/26127 * include/tr1/hashtable (hashtable::key_equal): Define. (hashtable::bucket, rehash_base::max_load_factor): Fix. * testsuite/tr1/6_containers/unordered/hashtable/26127.cc: New. Added: trunk/libstdc++-v3/testsuite/tr1/6_containers/unordered/hashtable/26127.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/tr1/hashtable -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26127
[Bug libstdc++/26127] tr1/hashtable compile errors
--- Comment #3 from paolo at gcc dot gnu dot org 2006-02-07 15:11 --- Subject: Bug 26127 Author: paolo Date: Tue Feb 7 15:11:34 2006 New Revision: 110698 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110698 Log: 2006-02-07 Paolo Carlini [EMAIL PROTECTED] * include/tr1/hashtable: Trivial formatting fixes. 2006-02-07 Paolo Carlini [EMAIL PROTECTED] Zak Kipling [EMAIL PROTECTED] PR libstdc++/26127 * include/tr1/hashtable (hashtable::key_equal): Define. (hashtable::bucket, rehash_base::max_load_factor): Fix. * testsuite/tr1/6_containers/unordered/hashtable/26127.cc: New. Added: branches/gcc-4_1-branch/libstdc++-v3/testsuite/tr1/6_containers/unordered/hashtable/26127.cc Modified: branches/gcc-4_1-branch/libstdc++-v3/ChangeLog branches/gcc-4_1-branch/libstdc++-v3/include/tr1/hashtable -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26127
[Bug libstdc++/26127] tr1/hashtable compile errors
--- Comment #4 from pcarlini at suse dot de 2006-02-07 15:13 --- Fixed for 4.1.0. -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26127
[Bug c++/26140] [4.2 Regression] ice on valid C++ code
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-02-07 15:36 --- Subject: Bug 26140 Author: rguenth Date: Tue Feb 7 15:36:44 2006 New Revision: 110699 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110699 Log: 2006-02-07 Richard Guenther [EMAIL PROTECTED] PR c++/26140 Revert 2006-01-30 Richard Guenther [EMAIL PROTECTED] PR c++/23372 * gimplify.c (gimplify_target_expr): Handle easy cases without creating a temporary. Revert 2006-01-30 Richard Guenther [EMAIL PROTECTED] PR c++/23372 * gcc.dg/pr23372-1.C: New testcase. * g++.dg/tree-ssa/pr26140.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr26140.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr23372-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26140
[Bug c++/23372] [4.0/4.1 Regression] Temporary aggregate copy not elided when passing parameters by value
--- Comment #27 from rguenth at gcc dot gnu dot org 2006-02-07 15:36 --- Subject: Bug 23372 Author: rguenth Date: Tue Feb 7 15:36:44 2006 New Revision: 110699 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110699 Log: 2006-02-07 Richard Guenther [EMAIL PROTECTED] PR c++/26140 Revert 2006-01-30 Richard Guenther [EMAIL PROTECTED] PR c++/23372 * gimplify.c (gimplify_target_expr): Handle easy cases without creating a temporary. Revert 2006-01-30 Richard Guenther [EMAIL PROTECTED] PR c++/23372 * gcc.dg/pr23372-1.C: New testcase. * g++.dg/tree-ssa/pr26140.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr26140.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr23372-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23372
[Bug testsuite/26159] New: pr23382.c and critical-3.c don't cleanup after themselves
I noticed while testing a patch and rerunning the testsuite, I still had the following files in the testsuite directory: critical-3.c.t26.ompexp pr23382.c.t67.alias6 -- Summary: pr23382.c and critical-3.c don't cleanup after themselves Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26159
[Bug c++/26140] [4.2 Regression] ice on valid C++ code
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-02-07 15:39 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26140
[Bug c++/23372] [4.0/4.1/4.2 Regression] Temporary aggregate copy not elided when passing parameters by value
--- Comment #28 from rguenth at gcc dot gnu dot org 2006-02-07 15:39 --- So we regress for 4.2 again as the patch caused problems. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.0.0 4.1.0 |4.0.0 4.1.0 4.2.0 Known to work|3.4.0 3.3.3 3.2.3 3.0.4 |3.4.0 3.3.3 3.2.3 3.0.4 |2.95.3 4.2.0|2.95.3 Summary|[4.0/4.1 Regression]|[4.0/4.1/4.2 Regression] |Temporary aggregate copy not|Temporary aggregate copy not |elided when passing |elided when passing |parameters by value |parameters by value http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23372
[Bug bootstrap/26050] [4.2 Regression] Use of u_int32_t in libgcc-math breaks bootstrap on Solaris 10/x86
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-02-07 15:40 --- 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=26050
[Bug tree-optimization/26135] store copyprop not effective
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-02-07 15:46 --- Patch posted. As DOM nearly handles all store copyprop I wonder if (this late) store copyprop is worth it. If not going to copyprop on steroids which I'm going to clean up again and re-submit. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||02/msg00559.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26135
[Bug middle-end/26134] fold *(float*)(complex_float_var) into REALPART_EXPRcomplex_float_var
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-07 15:49 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00560.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||02/msg00560.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26134
[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij
--- Comment #18 from hjl at lucon dot org 2006-02-07 16:16 --- There are [EMAIL PROTECTED] gcc]$ readelf -d /usr/gcc-4.2/bin/gij | grep RPATH 0x000f (RPATH) Library rpath: [/usr/gcc-4.2/lib/../lib64] [EMAIL PROTECTED] gcc]$ Why do I want [EMAIL PROTECTED] gcc]$ readelf -d /usr/gcc-4.2/bin/gij | grep RPATH 0x000f (RPATH) Library rpath: /export/build/gnu/gcc/build-x86_64-linux/gcc 0x000f (RPATH) Library rpath: [/usr/gcc-4.2/lib/../lib64] [EMAIL PROTECTED] gcc]$ It may cause more problems than it solves. -- hjl at lucon dot org changed: What|Removed |Added Last reconfirmed|2004-09-16 00:11:49 |2006-02-07 16:16:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311
[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij
--- Comment #19 from Ralf dot Wildenhues at gmx dot de 2006-02-07 16:28 --- (In reply to comment #18) Why do I want [EMAIL PROTECTED] gcc]$ readelf -d /usr/gcc-4.2/bin/gij | grep RPATH 0x000f (RPATH) Library rpath: /export/build/gnu/gcc/build-x86_64-linux/gcc 0x000f (RPATH) Library rpath: [/usr/gcc-4.2/lib/../lib64] [EMAIL PROTECTED] gcc]$ It may cause more problems than it solves. Certainly, that's a bad bug and has to be avoided at all (the fact that this may not work correctly now is clear: libtool does not yet fully support what I outlined). Where was I talking about the desire to have run paths in *installed programs* pointing *to the build tree* though? Maybe my notation was bad: a relinked-upon-execution executable is some program .libs/lt-foo inside the build tree that gets created when foo is executed; foo is a shell script that does this. Does this make things clearer now? Sorry for the confusion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311
[Bug target/22097] libgfortran build failure on mips-sgi-irix6.5
--- Comment #18 from r dot emrich at de dot tecosim dot com 2006-02-07 16:35 --- Created an attachment (id=10796) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10796action=view) fixes bootstrap failure in libgfortran/instrisics/c99_functions.c for mips-sgi-irix6.5 second version Okay, second try. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22097
[Bug tree-optimization/26135] store copyprop not effective
--- Comment #3 from steven at gcc dot gnu dot org 2006-02-07 16:35 --- In fact DOM should probably not be doing store copyprop, and store copyprop is simply broken. It never worked quite the way it should, so if you want to implement a better one, great! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26135
[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij
--- Comment #20 from hjl at lucon dot org 2006-02-07 16:48 --- What did you mean by *installed programs*. The executable in question is [EMAIL PROTECTED] .libs]$ readelf -d /export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava/.libs/gij | grep RPATH 0x000f (RPATH) Library rpath: [/usr/gcc-4.2/lib/../lib64] Is is your *installed programs*? My point is when you run a newly built executable in the build tree, it should use the newly built shared libraries in the build tree. It is a long standing bug in gcc/libtool. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311
[Bug tree-optimization/26144] with -O3 and pointer casts, gcc skips if
--- Comment #2 from devin at freeshell dot org 2006-02-07 17:07 --- I could reproduce it with that dated build. And it isn't just debian but also the buildroot gcc. Here is the assembly produced from -O3. Following that is the assembly from -O2. What seems to happen is that with -O3 foo() is optimized out and in it's place .LC0 is stored on the stack. Seems fine. But then the original value of ptr is used for calling printf instead of the updated value from the stack. .file test.c .section.rodata.str1.1,aMS,@progbits,1 .LC0: .string .text .p2align 4,,15 .globl foo .type foo, @function foo: pushl %ebp movl%esp, %ebp movl8(%ebp), %eax movl$.LC0, (%eax) popl%ebp ret .size foo, .-foo .section.rodata.str1.1 .LC1: .string %p .text .p2align 4,,15 .globl main .type main, @function main: pushl %ebp movl%esp, %ebp subl$24, %esp movl12(%ebp), %eax andl$-16, %esp subl$16, %esp movl4(%eax), %eax testl %eax, %eax movl%eax, -4(%ebp) je .L8 movl%eax, 4(%esp) movl$.LC1, (%esp) callprintf xorl%eax, %eax leave ret .p2align 4,,7 .L8: movl$.LC0, -4(%ebp) movl%eax, 4(%esp) movl$.LC1, (%esp) callprintf xorl%eax, %eax leave ret .size main, .-main .ident GCC: (GNU) 4.0.3 20060128 (prerelease) (Debian 4.0.2-8) .section.note.GNU-stack,,@progbits ## Correct Version # .file test.c .section.rodata.str1.1,aMS,@progbits,1 .LC0: .string .text .p2align 4,,15 .globl foo .type foo, @function foo: pushl %ebp movl%esp, %ebp movl8(%ebp), %eax movl$.LC0, (%eax) popl%ebp ret .size foo, .-foo .section.rodata.str1.1 .LC1: .string %p .text .p2align 4,,15 .globl main .type main, @function main: pushl %ebp movl%esp, %ebp subl$24, %esp movl12(%ebp), %eax andl$-16, %esp subl$16, %esp movl4(%eax), %eax testl %eax, %eax movl%eax, -4(%ebp) je .L8 movl-4(%ebp), %eax movl$.LC1, (%esp) movl%eax, 4(%esp) callprintf xorl%eax, %eax leave ret .p2align 4,,7 .L8: leal-4(%ebp), %eax movl%eax, (%esp) callfoo movl-4(%ebp), %eax movl$.LC1, (%esp) movl%eax, 4(%esp) callprintf xorl%eax, %eax leave ret .size main, .-main .ident GCC: (GNU) 4.0.3 20060128 (prerelease) (Debian 4.0.2-8) .section.note.GNU-stack,,@progbits -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26144
[Bug bootstrap/26161] New: Configure tests for pthread.h sometimes need to use -pthread
The problem is that on some systems, including Tru64 and I believe AIX, the compiler has to be passed the -pthread command line option in order to use #include pthread.h Effectively, the first lines of /usr/include/pthread.h contain the lines: #ifndef _REENTRANT #error POSIX pthreads are only available with the use of -pthreads #endif For this reason the autoconf tests of pthread.h in libstdc++-v3 and libgomp always fail. Fortunately, this was previously not serious, as the target configurations would include pthread.h anyway, and all the relevant source libraries are compiled with -pthread. In directories where they don't, GCC has workarounds, such as in gcc/gcc-posix.h which contains the lines: /* Some implementations of pthread.h require this to be defined. */ #ifndef _REENTRANT #define _REENTRANT 1 #endif #include pthread.h This issue escalcated to a bootstrap failure in libgomp recently, which now aborts whilst configuring libgomp when pthread.h isn't detected. Prior to this change, libgomp built fine and the test results were quite reasonable on Alpha/Tru64. [Stretching the definition of a regression :-)] I believe that what is needed is a local configure test for pthread.h that first decides whether the compiler supports -pthread (for example, GCC on IRIX currently does not), and then uses this flag testing for headers. This is perhaps similar to the related patch I posted recently, where we need to test system header with the same compiler options we'll be using to build the source files: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00139.html See the related definitions of THREADCXXFLAGS and THREADLDFLAGS in libjava's configure.ac. Unfortunately, my autoconf-fu isn't strong enough to tackle this. The temporary work-around is to use --disable-libgomp. The long-term fix would be to port libgomp to use GCC's gthreads library. But in the meantime, it would be good to correct the test for pthread.h and/or add a PTHREAD_CFLAGS that can be used any project. I'm happy to test patches on affected systems. However, it should be trivial to re-create a model system with the above lines and using -D_REENTRANT as the compiler option that needs to be passed. -- Summary: Configure tests for pthread.h sometimes need to use - pthread Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: roger at eyesopen dot com GCC host triplet: alpha*-*-osf* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26161
[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij
--- Comment #21 from Ralf dot Wildenhues at gmx dot de 2006-02-07 17:18 --- (In reply to comment #20) What did you mean by *installed programs* In my notation, installed programs live below $prefix. They must not contain any reference to the build tree. You showed an installed program in comment #18, which has an erroneous run path. The executable in question is [EMAIL PROTECTED] .libs]$ readelf -d /export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava/.libs/gij | grep RPATH 0x000f (RPATH) Library rpath: [/usr/gcc-4.2/lib/../lib64] This is an uninstalled program: it lives below $builddir. It should of course have a run path entry to the newly-built library (which also lives below $builddir). One of my points was that, if that uninstalled program also has a run path entry pointing to /usr/gcc-4.2/lib/../lib64, but that comes after all the run paths which point to inside $builddir, then that is not a big problem. Is is your *installed programs*? No. My point is when you run a newly built executable in the build tree, it should use the newly built shared libraries in the build tree. It is a long standing bug in gcc/libtool. Yes, correct. It's one of my medium term quests to fix this. The converse issue (from a libtool POV) is just GCC bug 5291. Again from a libtool POV it is convenient and useful to attack both issues at the same time. One of the open questions that I could not answer myself yet: When you issue `make install' for GCC, is there a guarantee by the GCC build machinery that - libraries are installed in the correct order (libgcc_s.so before libgcj)? I strongly assume yes. - For each libtool-created library, in case it needs to be relinked at install time, does the relink command have appropriate -L (and maybe -R) flags pointing to the installed non-libtool libraries (e.g., $prefix/lib/libgcc_s)? In comment #18, you show that for this build, the second question is true. I need to know however if it is true in any case, for any value of $host. Iff both questions can be affirmed, then the next question can also be made true: - If libtool erased both all `-L' and all `-R' flags pointing inside the build tree from the relink command that may be issued at `make install' time, would installation still succeed? Then we have a chance to fix this portably in libtool, not only for GNU/Linux. Another small but important question: - Do there exist directories in the GCC build tree where both libtool-created and non-libtool-created libraries are (possibly) built? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311
[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij
--- Comment #22 from hjl at lucon dot org 2006-02-07 17:25 --- Another small but important question: - Do there exist directories in the GCC build tree where both libtool-created and non-libtool-created libraries are (possibly) built? That is THE KEY question. The executable in question is lt-gij: [EMAIL PROTECTED] .libs]$ readelf -d /export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava/.libs/lt-gij | grep RPATH 0x000f (RPATH) Library rpath: [/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava/.libs] [EMAIL PROTECTED] .libs]$ libgcc_s.so.1 isn't built by libtool. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311
[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij
--- Comment #23 from Ralf dot Wildenhues at gmx dot de 2006-02-07 17:43 --- (In reply to comment #22) - Do there exist directories in the GCC build tree where both libtool-created and non-libtool-created libraries are (possibly) built? That is THE KEY question. The executable in question is lt-gij: [EMAIL PROTECTED] .libs]$ readelf -d /export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava/.libs/lt-gij | grep RPATH 0x000f (RPATH) Library rpath: [/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/libjava/.libs] [EMAIL PROTECTED] .libs]$ libgcc_s.so.1 isn't built by libtool. Yes, but the one is $stage/gcc/libgcc_s.so.1 and the other is $stage/x86_64-unknown-linux-gnu/libjava/lib/libgcj.la, so they are built in different directories. Libtool has to know that $stage/gcc is something that is necessary for the uninstalled link and run paths; but libtool also needs to be able to deduce that the path $stage/gcc must not be used for any installed libraries or programs. Now, if I want to fix this properly (in Libtool), then I need to know whether above question can be answered with yes not only for libgcc_s/libgcj, but for each library created in GCC. And also the other questions, really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311
[Bug ada/26162] New: GNAT BUG DETECTED in AWS
When compiling the AWS HEAD release I get the following Error message: +===GNAT BUG DETECTED==+ | 4.0.2 (x86_64-suse-linux-gnu) in emit_move_insn, bei expr.c:3092 | | Error detected at aws-url.adb:709:1 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. /work/act/AWS/src/aws-url.adb /work/act/AWS/src/aws-url.ads /work/act/AWS/src/aws.ads /work/act/AWS/src/aws-messages.ads /work/act/AWS/src/aws-utils.ads /work/act/AWS/include/zlib.ads /work/act/AWS/src/aws-url-raise_url_error.ads /work/act/AWS/src/aws-messages.adb raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:387 gnatmake: /work/act/AWS/src/aws-url.adb compilation error And the obligatoric gcc -v: LANG=C gcc -v Using built-in specs. Target: x86_64-suse-linux Configured with: ../gcc-4.0.2/configure --with-gcc --with-gnu-ld --with-gnu-as --enable-alloca=yes --enable-mpfr --enable-libada --enable-libgcj --enable-multilib --enable-java-gc=boehm --enable-c99 --enable-threads=yes --enable-interpreter --enable-hash-synchronization --enable-shared --prefix=/opt/gnat/gcc --enable-languages=c,ada,c++,f95,java,objc x86_64-suse-linux Thread model: posix gcc version 4.0.2 Martin -- Summary: GNAT BUG DETECTED in AWS Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: krischik at users dot sourceforge dot net GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26162
[Bug ada/26162] GNAT BUG DETECTED in AWS
--- Comment #1 from krischik at users dot sourceforge dot net 2006-02-07 17:51 --- Created an attachment (id=10797) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10797action=view) The sources, concatternated and ziped up. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26162
[Bug ada/26162] GNAT BUG DETECTED in AWS
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-07 18:11 --- What options were you compiling with? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26162
[Bug middle-end/26163] New: [meta-bug] missed optimization in SPEC (2k and 2k6 and 95)
Just a meta-bug for all the missed optimizations that are known currently in the SPEC benchmarks. -- Summary: [meta-bug] missed optimization in SPEC (2k and 2k6 and 95) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k and 2k6 and 95)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-07 18:16:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug java/12758] Binary Compatibility: CNI code is not binary compatible
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12758
[Bug java/26152] gtkImage.c complains and crashes the application
--- Comment #6 from tromey at gcc dot gnu dot org 2006-02-07 18:28 --- You can't build just the gcj bits of gcc -- you have to build the whole thing. There are instructions on the gcc web site: http://gcc.gnu.org/install/ BTW, thanks for the self-contained bug report. We like to see reports like this, since it makes it much simpler for us to see what is going wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26152
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k and 2k6 and 95)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-07 18:29 --- IIRC 17959 shows up in craft on powerpc. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||17959 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug java/22377] BC compilation fails to detect abstract instantiation
--- Comment #3 from tromey at gcc dot gnu dot org 2006-02-07 18:43 --- Andrew pointed out on irc that we could also implement this by installing a pointer to a constructor which would simply throw the appropriate exception. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22377
[Bug libgcj/17311] Wrong libgcc_s.so.1 is used by lt-gij
--- Comment #24 from hjl at lucon dot org 2006-02-07 18:45 --- For uninstalled executables in the build tree, like lt-gij, libtool may put all directories, which are in the build tree, passed by -L, into DT_RPATH. It may add more DT_RPATH entries than necessary. If you want fancy one, you can check out how linker deccides the library in which directory to use. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311
[Bug middle-end/26134] fold *(float*)(complex_float_var) into REALPART_EXPRcomplex_float_var
--- Comment #4 from pluto at agmk dot net 2006-02-07 18:47 ---
I see here another missed optimization on x86-64.
float re(float _Complex a) { return __real__ a; }
# gcc-4.1:
re: movq%xmm0, -8(%rsp)
movss -8(%rsp), %xmm0
ret
we can use `movss %xmm0, %xmm0` here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26134
[Bug middle-end/26134] fold *(float*)(complex_float_var) into REALPART_EXPRcomplex_float_var
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-07 18:52 ---
(In reply to comment #4)
I see here another missed optimization on x86-64.
float re(float _Complex a) { return __real__ a; }
That is a totally different issue and should filed as a different bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26134
[Bug middle-end/26134] fold *(float*)(complex_float_var) into REALPART_EXPRcomplex_float_var
--- Comment #6 from falk at debian dot org 2006-02-07 18:55 ---
(In reply to comment #5)
(In reply to comment #4)
I see here another missed optimization on x86-64.
float re(float _Complex a) { return __real__ a; }
That is a totally different issue and should filed as a different bug.
Probably related to PR 7061.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26134
[Bug java/25535] gcj broken on 64-bit big-endian systems
--- Comment #4 from aph at gcc dot gnu dot org 2006-02-07 19:02 --- Subject: Bug 25535 Author: aph Date: Tue Feb 7 19:02:39 2006 New Revision: 110710 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110710 Log: 2006-02-07 Andrew Haley [EMAIL PROTECTED] * expr.c (expand_invoke): (BC mode.) If we find a method in a class other than the one in which we expected to find it, ignore the result. PR java/25535 * constants.c (build_constants_constructor): move initializer into first halfword on a 6-bit big-endian machine. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/constants.c trunk/gcc/java/expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25535
[Bug java/26138] Lots of warnings with gcj .jar - .so
--- Comment #3 from tromey at gcc dot gnu dot org 2006-02-07 19:23 --- I looked at this a bit more. We don't want to set TREE_USED on the itable syms decl, because that will still cause it to be emitted, even though it is not used. It would be preferable to not create the various decls here unless we know for sure that they will be used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26138
[Bug tree-optimization/21559] [4.1/4.2 Regression] missed jump threading
--- Comment #7 from law at redhat dot com 2006-02-07 20:03 --- With today's changes we thread the break edge out of the loop. We could still do better. Basically we need to realize that bytes can never have the value zero when we hit the loop test while (toread != 0). Once we realize that, then we'd know that the test (if bytes == 0) has a known result on all paths reaching the conditional. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21559
[Bug java/22578] should inline floatToIntBits et al
--- Comment #2 from tromey at gcc dot gnu dot org 2006-02-07 20:12 --- Testing a patch -- 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-01-15 20:04:50 |2006-02-07 20:12:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22578
[Bug ada/26162] GNAT BUG DETECTED in AWS
--- Comment #3 from krischik at users dot sourceforge dot net 2006-02-07 20:23 --- Sorry, allways forget. Here it comes: gcc -c -gnatwecfijkmruv -gnaty3abcefhiklmnoprstx -Wall -O2 -gnatn -I- -gnatA /work/act/AWS/src/aws-url.adb With Regards Martin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26162
[Bug bootstrap/26161] Configure tests for pthread.h sometimes need to use -pthread
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-02-07 20:24
---
I tried to give it a look on alphaev68-dec-osf5.1b, but I couldn't get to the
point of configuring libgomp :)
cc -c -DHAVE_CONFIG_H -g -I. -I../../gcc/libiberty/../include -Wc++-compat
../../gcc/libiberty/floatformat.c -o ./floatformat.o
cc: Error: ../../gcc/libiberty/floatformat.c, line 343: In this statement, the
libraries on this platform do not yet support compile-time evaluation of the
constant expression 0.0/0.0. (constfoldns)
dto = NAN;
Doesn't the following work?
Index: libgomp/configure.tgt
===
--- libgomp/configure.tgt (revision 110617)
+++ libgomp/configure.tgt (working copy)
@@ -29,6 +29,10 @@
config_path=linux/alpha linux posix
;;
+alpha*-dec-osf*)
+ XCFLAGS=${XCFLAGS} -pthread
+ ;;
+
ia64*-*-linux*)
config_path=linux/ia64 linux posix
;;
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26161
[Bug bootstrap/26161] Configure tests for pthread.h sometimes need to use -pthread
--- Comment #2 from roger at eyesopen dot com 2006-02-07 21:15 --- I've discovered your bootstrap failure is PR16787. It'll take a while for me to try out your XCFLAGS fix on my slow machine. I'll also propose a fix for PR16787. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26161
[Bug tree-optimization/21417] Missed jump threading opportunity on trees
--- Comment #4 from law at redhat dot com 2006-02-07 21:24 --- The jump threading code is *very* conservative when threading across a backedge in the CFG. The fundamental issue is that you'll have the result of the conditional in your hash tables from the normal DOM walk and you may (incorrectly) use that result. ie, think about the case where you've got something like this at the head of a loop x = y-z if (x == 42) ... If you traverse a backedge to that block and try to thread through the block, you can get incorrect results since you'll have recorded knowledge about x in your hash tables already, but x's value may change from one iteration to the next. Threading the backedge *is* safe when statements in the target block do not affect the result of the conditional at the end of the target block. I found that handling the trivial case (there are *no* statements other than the conditional) caught most of the cases of threadable backedges I had encountered. It shouldn't be terribly hard to look at the operands of the conditional and allow threading a backedge if the operands of the conditional are not set in statements in the same block as the conditional. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21417
[Bug libfortran/25577] gfortran routine mvbits returns wrong answer.
--- Comment #6 from dir at lanl dot gov 2006-02-07 21:24 --- Trouble with my internet access since Feb 1 - I am getting no Email, etc.. . I am on a new wonderful automatic system - They say that I should be up about 3 days after my account is reset. Multiple servers with ,of course, only one server update a night. Now, if they could find somebody that knows how to reset my account. If you would FX, please be my guest - submit it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25577
[Bug libgomp/26165] New: Cannot find libgomp.spec after 'make install' on x86_64 and ppc64
After 'make install', the installed compiler cannot find libgomp.spec. The problem seems to be that we are not looking in inst/lib64: $ export PATH=$HOME/gomp.clean/native.x86_64/bin:$PATH $ which gcc ~/gomp.clean/native.x86_64/bin/gcc $ gcc -o a a.c -fopenmp -O2 a.c: In function 'main': gcc: libgomp.spec: No such file or directory $ find ~/gomp.clean/native.x86_64 -name libgomp.spec /home/cygnus/dnovillo/gomp.clean/native.x86_64/lib64/libgomp.spec $ cp /home/cygnus/dnovillo/gomp.clean/native.x86_64/lib64/libgomp.spec /home/cygnus/dnovillo/gomp.clean/native.x86_64/lib/libgomp.spec $ gcc -o a a.c -fopenmp -O2 $ ./a ./a: error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory $ export LD_LIBRARY_PATH=$HOME/gomp.clean/native.x86_64/lib64:$LD_LIBRARY_PATH $ ./a I'm thread 0 I'm thread 3 I'm thread 1 I'm thread 2 Perhaps the two problems are related? This works just fine on x86. We neither have to set LD_LIBRARY_PATH by hand nor we need to move libgomp.spec around. -- Summary: Cannot find libgomp.spec after 'make install' on x86_64 and ppc64 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dnovillo at gcc dot gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26165
[Bug c++/18150] Should enable -Wsequence-point for C++
--- Comment #4 from mueller at gcc dot gnu dot org 2006-02-07 21:47 --- Subject: Bug 18150 Author: mueller Date: Tue Feb 7 21:47:55 2006 New Revision: 110719 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110719 Log: 2006-02-07 Dirk Mueller [EMAIL PROTECTED] PR c++/18150 * doc/invoke.texi (-Wsequence-point): Update documentation that -Wsequence-point is implemented for C++ as well. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18150
[Bug libfortran/25577] gfortran routine mvbits returns wrong answer.
--- Comment #7 from tobi at gcc dot gnu dot org 2006-02-07 22:04 --- I shall commit this as obvious once I have distilled a testcase. FAICR the original code is by me, and the change is certainly obvious. -- tobi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-02-04 08:34:25 |2006-02-07 22:04:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25577
[Bug target/26109] ICE: Segmentation fault (program cc1) compiling _muldi3.o in stage1
--- Comment #2 from danglin at gcc dot gnu dot org 2006-02-07 22:09 --- Subject: Bug 26109 Author: danglin Date: Tue Feb 7 22:09:52 2006 New Revision: 110721 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110721 Log: PR target/26109 * pa.c (attr_length_indirect_call): Don't return length 8 for distances = 24 when generating code for SOM runtime. (output_indirect_call): Don't use b,l instruction for indirect calls to $$dyncall when generating code for SOM runtime.. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26109
[Bug target/26109] ICE: Segmentation fault (program cc1) compiling _muldi3.o in stage1
--- Comment #3 from danglin at gcc dot gnu dot org 2006-02-07 22:11 --- Subject: Bug 26109 Author: danglin Date: Tue Feb 7 22:11:30 2006 New Revision: 110722 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110722 Log: PR target/26109 * pa.c (attr_length_indirect_call): Don't return length 8 for distances = 24 when generating code for SOM runtime. (output_indirect_call): Don't use b,l instruction for indirect calls to $$dyncall when generating code for SOM runtime.. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/pa/pa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26109
[Bug target/26109] ICE: Segmentation fault (program cc1) compiling _muldi3.o in stage1
--- Comment #4 from danglin at gcc dot gnu dot org 2006-02-07 22:13 --- Subject: Bug 26109 Author: danglin Date: Tue Feb 7 22:13:22 2006 New Revision: 110723 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110723 Log: PR target/26109 * pa.c (attr_length_indirect_call): Don't return length 8 for distances = 24 when generating code for SOM runtime. (output_indirect_call): Don't use b,l instruction for indirect calls to $$dyncall when generating code for SOM runtime.. Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/config/pa/pa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26109
[Bug target/26109] ICE: Segmentation fault (program cc1) compiling _muldi3.o in stage1
--- Comment #5 from danglin at gcc dot gnu dot org 2006-02-07 22:15 --- Subject: Bug 26109 Author: danglin Date: Tue Feb 7 22:15:30 2006 New Revision: 110724 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110724 Log: PR target/26109 * pa.c (attr_length_indirect_call): Don't return length 8 for distances = 24 when generating code for SOM runtime. (output_indirect_call): Don't use b,l instruction for indirect calls to $$dyncall when generating code for SOM runtime.. Modified: branches/gcc-3_4-branch/gcc/ChangeLog branches/gcc-3_4-branch/gcc/config/pa/pa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26109
[Bug target/26109] ICE: Segmentation fault (program cc1) compiling _muldi3.o in stage1
--- Comment #6 from danglin at gcc dot gnu dot org 2006-02-07 22:17 --- Fixed by patch. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26109
[Bug c++/18150] Should enable -Wsequence-point for C++
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-07 22:59 --- Fixed. -- pinskia 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=18150
