[Bug fortran/5900] [g77 gfortran] Lapack regressions since g77 2.95.2
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-09 08:12 --- gfortran -c -O1 -fno-tree-ccp -fno-tree-ch -fno-tree-copyrename -fno-tree-dce -fno-tree-dominator-opts -fverbose-asm -fno-unswitch-loops -fno-peel-loops -fno-unroll-loops -fno-tree-dse -fno-tree-fre -fno-tree-loop-im -fno-tree-loop-ivcanon -fno-tree-loop-optimize -fno-tree-lrs -fno-tree-sra -fno-tree-ter -fno-loop-optimize -fverbose-asm ../*.f yields the following options: // options passed: -ffixed-form -auxbase -O1 -fno-tree-ccp -fno-tree-ch // -fno-tree-copyrename -fno-tree-dce -fno-tree-dominator-opts // -fverbose-asm -fno-unswitch-loops -fno-peel-loops -fno-unroll-loops // -fno-tree-dse -fno-tree-fre -fno-tree-loop-im -fno-tree-loop-ivcanon // -fno-tree-loop-optimize -fno-tree-lrs -fno-tree-sra -fno-tree-ter // -fno-loop-optimize // options enabled: -falign-loops -fargument-noalias-global // -fbranch-count-reg -fcommon -fcprop-registers -fdefer-pop // -feliminate-unused-debug-types -ffunction-cse -fgcse-lm // -fguess-branch-probability -fident -fif-conversion -fif-conversion2 // -fivopts -fkeep-static-consts -fleading-underscore -floop-optimize2 // -fmath-errno -fmerge-constants -fomit-frame-pointer -fpeephole // -freg-struct-return -fsched-interblock -fsched-spec // -fsched-stalled-insns-dep -fsplit-ivs-in-unroller -ftrapping-math // -funwind-tables -fverbose-asm -fzero-initialized-in-bss -mgnu-as // -mgnu-ld -minline-float-divide-max-throughput -mdwarf2-asm // -mtune=itanium2 and no change in the failures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
[Bug preprocessor/17798] [3.4/4.0 Regression] high cpp memory usage with undefined symbols
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-02-09 08:13 --- This is nowhere near release-critical; it's an intentional extreme corner case. As for the facts noted in the audit trail (i.e., that we lex the whole file up front, and that we keep all identifiers around the entire time), those are very sound strategies for most programs. I've removed the target milestone, and closed as WONTFIX. If someone chooses to reopen this, please do not reset the target milestone. -- What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX Target Milestone|3.4.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17798
[Bug regression/19120] [4.0 Regression] ICE: in ten_to_ptwo, at real.c:2007
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-09 08:51 --- Same question as in comment 3: Does this problem still happen? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19120
[Bug AWT/19838] New: Repaint-Loop due to setBackground()
Calls to setBackground() inside paint() cause an infinite repaint-loop, because setBackground() unconditionally causes a repaint(). This does not occur with JDK 1.1 .. 5.0 We might want to check whether the background color changes... -- Summary: Repaint-Loop due to setBackground() Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: hendrich at informatik dot uni-hamburg dot de CC: fitzsim at redhat dot com,gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19838
[Bug AWT/19839] New: Repaint-loop due to createImage() and non-null ImageObserver
Calling Graphics.drawImage( image, x, y, observer ) results in an endless repaint loop when observer is non null and the image was retrieved via Component.createImage(width,height). Note: this does not happen for Image's created via Toolkit.getImage()... Testcase follows -- Summary: Repaint-loop due to createImage() and non-null ImageObserver Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: hendrich at informatik dot uni-hamburg dot de CC: fitzsim at redhat dot com,gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19839
[Bug AWT/19838] Repaint-Loop due to setBackground()
--- Additional Comments From hendrich at informatik dot uni-hamburg dot de 2005-02-09 09:22 --- Created an attachment (id=8148) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8148action=view) Demonstrates the repaint loop -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19838
[Bug AWT/19839] Repaint-loop due to createImage() and non-null ImageObserver
--- Additional Comments From hendrich at informatik dot uni-hamburg dot de 2005-02-09 09:24 --- Created an attachment (id=8149) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8149action=view) Demonstrates the repaint loop -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19839
[Bug AWT/19839] Repaint-loop due to createImage() and non-null ImageObserver
--- Additional Comments From hendrich at informatik dot uni-hamburg dot de 2005-02-09 09:27 --- Changing the call to drawImage( image, x, y, null ) makes the program work. However, an Image create by createImage(width,height) should be completely initialized at once: there is no image data to read asynchronously... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19839
[Bug AWT/19840] New: drawImage bug
The attached program demonstrates the (wrong) behaviour of the 'synchronous' variants of java.awt.Graphics.drawImage when asked to draw to 'negative' offsets. Both Canvas'es should look the same, but current libgcj does shift the image to the bottom right instead of to the upper left... -- Summary: drawImage bug Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: hendrich at informatik dot uni-hamburg dot de CC: fitzsim at redhat dot com,gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19840
[Bug AWT/19840] drawImage bug
--- Additional Comments From hendrich at informatik dot uni-hamburg dot de 2005-02-09 09:30 --- Created an attachment (id=8150) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8150action=view) testcase for the bug, both images should look the same -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19840
[Bug libstdc++/19495] basic_string::_M_rep() can produce an unnaturally aligned pointer to _Rep
--- Additional Comments From pcarlini at suse dot de 2005-02-09 09:33 --- Will be trivially fixed in v7... -- What|Removed |Added Status|ASSIGNED|SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495
[Bug java/19841] New: Inner classes problem
gcj fails to compile the following testcases, while jikes, javac, and Eclipse
allow the code. (Might be a duplicate of existing inner classes problem
reports.)
/* GCJ inner class problem */
import java.awt.*;
public class SSS extends Canvas {
int state = 0;
public class Selector extends Dialog {
public Selector( Frame parent ) {
super( parent );
}
public void foo() {
state = 42;
}
}
}
--
Summary: Inner classes problem
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hendrich at informatik dot uni-hamburg dot de
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19841
[Bug AWT/19842] New: MouseEvent ignores Button2 and Button3
The attached testcase demonstrates the java.awt.event.MouseEvent internally knows about the middle and right mouse buttons (because the correct data shows up in event.toString()). However, querying those values via getButton() or getModifiers() or InputEvent.isAltDown() / isMetaDown() always returns false. This makes it impossible to detect middle/right button clicks in user programs. Testcase usage: compile and run, then try mouse-clicks on the frame using all mouse buttons and the (shift/alt/meta/control)-key+button1 variants. Might use java.awt.Robot to automate... -- Summary: MouseEvent ignores Button2 and Button3 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: hendrich at informatik dot uni-hamburg dot de CC: fitzsim at redhat dot com,gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19842
[Bug AWT/19842] MouseEvent ignores Button2 and Button3
--- Additional Comments From hendrich at informatik dot uni-hamburg dot de 2005-02-09 09:39 --- Created an attachment (id=8152) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8152action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19842
[Bug AWT/19843] New: AWT program ignores System.exit()
On my system, the attached testcase (actually the same testcase as used for bug 19839) randomly fails to terminate despite the calls to System.exit() at the end of the main() method. This occurs approximately on every tenth invocation of the program on my system. I suspect some thread-issue related to the high repaint()-load created by the program. (Linux 2.4.20, SuSE 8.2, gcc-4.0-20050130 snapshot) -- Summary: AWT program ignores System.exit() Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: hendrich at informatik dot uni-hamburg dot de CC: fitzsim at redhat dot com,gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19843
[Bug AWT/19843] AWT program ignores System.exit()
--- Additional Comments From hendrich at informatik dot uni-hamburg dot de 2005-02-09 09:44 --- Created an attachment (id=8153) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8153action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19843
[Bug AWT/19844] New: Swing components ignore key events
non-text Swing components seem to ignore key-events completely. No small testcase yet. Can be demonstrated via the program attached to http://gcc.gnu.org/ml/java/2005-02/msg00016.html (The main ImageCanvas never receives its key events). -- Summary: Swing components ignore key events Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: hendrich at informatik dot uni-hamburg dot de CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19844
[Bug AWT/19845] New: Swing ToolTipManager and getLocationOnScreen
javax.swing.ToolTipManager causes (eternal) NullPointerExceptions when JToolTips are enabled on non-showing JComponents, e.g. on not-yet-shown dialog windows or just-closed dialog windows. If the bug happens, Swing is unusable, because the main GUI thread never recovers from the NPEs. ToolTipManager should probably ignore non-showing components and should be more robust... I have no small testcase, but a typical stack trace looks like this: Exception during event dispatch: java.awt.IllegalComponentStateException: component not showing at java.awt.Component.getLocationOnScreen() (/opt/gcc40/lib/libgcj.so.6.0.0) at javax.swing.SwingUtilities.convertPointFromScreen(java.awt.Point, java.awt.Component) (/opt/gcc40/lib/libgcj.so.6.0.0) at javax.swing.SwingUtilities.convertPoint(java.awt.Component, int, int, java.awt.Component) (/opt/gcc40/lib/libgcj.so.6.0.0) at javax.swing.SwingUtilities.convertPoint(java.awt.Component, java.awt.Point, java.awt.Component) (/opt/gcc40/lib/libgcj.so.6.0.0) at javax.swing.ToolTipManager.getContentPaneDeepestComponent(java.awt.event.MouseEvent) (/opt/gcc40/lib/libgcj.so.6.0.0) at javax.swing.ToolTipManager.mouseExited(java.awt.event.MouseEvent) (/opt/gcc40/lib/libgcj.so.6.0.0) -- Summary: Swing ToolTipManager and getLocationOnScreen Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: hendrich at informatik dot uni-hamburg dot de CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19845
[Bug AWT/19846] New: AWT Toolkit.createImage very slow
Loading images from files, inputstreams, or URLs via the variants of Toolkit.getImage( ... ) is incredibly slow in gcc-4.0-20050130. Even creating a few small icons incurs noticable overhead (some seconds) on my Athlon 2600+. Loading JPG-images of ~800x600 pixels can take over ten seconds. No seperate testcase, but you can use the testcase for bug 19839 (supply a bigger image instead of the small 64x64 icons) or the program attached to http://gcc.gnu.org/ml/java/2005-02/msg00016.html -- Summary: AWT Toolkit.createImage very slow Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: hendrich at informatik dot uni-hamburg dot de CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19846
[Bug AWT/19840] drawImage bug
--- Additional Comments From hendrich at informatik dot uni-hamburg dot de 2005-02-09 10:15 --- Created an attachment (id=8154) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8154action=view) demo image for the testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19840
[Bug AWT/19847] New: AWT drawImage fails to render transparent GIFs
Try running the testcase for bug 19840 (DrawImageBug) with the small 2-color transparent GIF image attached to this report. (Rename updatemodebutton.gif to jfig.gif for the program to find the image or edit the testcase). The image is not drawn at all; this seems only to occur for transparent black-and-white (2 colors) GIFs. Might be a bug in drawImage() or getImage(). -- Summary: AWT drawImage fails to render transparent GIFs Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: hendrich at informatik dot uni-hamburg dot de CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19847
[Bug AWT/19847] AWT drawImage fails to render transparent GIFs
--- Additional Comments From hendrich at informatik dot uni-hamburg dot de 2005-02-09 10:20 --- Created an attachment (id=8155) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8155action=view) demo image for testcase rename to 'jfig.gif' and run 'DrawImageBug' from bug 19840. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19847
[Bug c++/19739] [3.4/4.0 Regression] ICE with additional comma in attribute
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-09 10:23 --- (From update of attachment 8151) Except that it is an ICE on _valid_, not invalid. Bogus patch. -- What|Removed |Added Attachment #8151 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19739
[Bug preprocessor/15220] [3.3/3.4/4.0 regression] gcc -E -MM -MG reports missing system headers in source directory
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-09 10:37 --- I don't see why this is critical. -- What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15220
[Bug libgcj/19823] java fails with non-executable memory
--- Additional Comments From aph at gcc dot gnu dot org 2005-02-09 10:47 --- I changed the gc settings to enable USE_MMAP on Linux. I had to do this because at least one Linux kernel didn't give exec permission on the heap. That change did work at the time. 2004-01-20 Andrew Haley [EMAIL PROTECTED] * include/private/gcconfig.h (USE_MMAP): Define for all Linux. -- What|Removed |Added CC||aph at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19823
Re: [Bug preprocessor/19836] -E -dD includes predefined macros
jason at catapult dot com wrote:- --- Additional Comments From jason at catapult dot com 2005-02-09 06:27 --- (In reply to comment #1) This is documented to do this so this is not a bug. I thought -dD was supposed to NOT include predefined macros? Use -undef if you don't want them.
[Bug preprocessor/19836] -E -dD includes predefined macros
--- Additional Comments From neil at daikokuya dot co dot uk 2005-02-09 11:06 --- Subject: Re: -E -dD includes predefined macros jason at catapult dot com wrote:- --- Additional Comments From jason at catapult dot com 2005-02-09 06:27 --- (In reply to comment #1) This is documented to do this so this is not a bug. I thought -dD was supposed to NOT include predefined macros? Use -undef if you don't want them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19836
[Bug middle-end/19807] fold does not fold a[4]-1
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-02-09
11:15 ---
Another testcase is the following:
xtern void link_error(void);
void foo(int i)
{
int a[4];
if ((char*)a[1] + 4*i + 4 != (char*)a[i+2])
link_error();
if (a[1] + i + 1 != a[i+2])
link_error();
}
which I have a patch for that works for C++ by extending the existing
try_move_mult_to_index and trying to avoid inserting (unsinged) casts
there.
Unfortunately, for C (whose initial trees do not contain ARRAY_REF exprs),
the frontend already inserts casts to unsigned (.03.generic):
foo (i)
{
charD.1 * a.0D.1129;
intD.0 D.1130;
charD.1 * D.1131;
charD.1 * D.1132;
charD.1 * D.1133;
unsigned intD.3 i.1D.1134;
unsigned intD.3 D.1135;
intD.0 * D.1136;
intD.0 * D.1137;
intD.0 * D.1138;
charD.1 * D.1139;
intD.0 aD.1128[4];
a.0D.1129 = (charD.1 *) aD.1128;
D.1130 = iD.1125 * 4;
D.1131 = (charD.1 *) D.1130;
D.1132 = a.0D.1129 + D.1131;
D.1133 = D.1132 + 8B;
i.1D.1134 = (unsigned intD.3) iD.1125;
D.1135 = i.1D.1134 * 4;
D.1136 = (intD.0 *) D.1135;
D.1137 = aD.1128 + D.1136;
D.1138 = D.1137 + 8B;
D.1139 = (charD.1 *) D.1138;
if (D.1133 != D.1139)
{
link_error ();
}
else
{
}
if (0)
{
link_error ();
}
else
{
}
}
which maybe even wrong, if not hindering optimizations at least.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2005-02-07 19:30:41 |2005-02-09 11:15:29
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19807
[Bug bootstrap/17383] [4.0 Regression] Building in src dir fails
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch 2005-02-09 12:30 --- Subject: Re: [4.0 Regression] Building in src dir fails I have considered doing this in the truly parallel way: namely, introducing HOST_SUBDIR to go along with BUILD_SUBDIR and TARGET_SUBDIR. I already have a patch for this queued for 4.1 and posted to gcc-patches. DJ however has a hackish fix that will go in once 4.0 branches. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17383
[Bug driver/19848] New: options passed from -verbose-asm do not adequately reflect optimization
This caused me a lot of pain in trying to disable specific optimizations with -O1. $ gfortran -O1 -o dasum-1.s -S -fverbose-asm -fno-loop-optimize -fno-tree-sra -fno-tree-ter -fno-omit-frame-pointer -fno-tree-dse -fno-tree-dominator-opts -fno-tree-ch -fno-tree-fre -fno-merge-constants -fno-cprop-registers -fno-if-conversion2 -fno-defer-pop -fno-tree-lrs -fno-guess-branch-probability -fno-tree-ccp -fno-tree-copyrename -fno-tree-dce -fno-if-conversion ../dasum.f $ gfortran -O0 -o dasum-0.s -S -fverbose-asm ../dasum.f $ diff -u dasum-0.s dasum-1.s | head -30 --- dasum-0.s 2005-02-09 13:38:52.0 +0100 +++ dasum-1.s 2005-02-09 13:38:46.0 +0100 @@ -3,7 +3,12 @@ // GNU F95 version 4.0.0 20050130 (experimental) (ia64-unknown-linux-gnu) // compiled by GNU C version 4.0.0 20050130 (experimental). // GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 -// options passed: -ffixed-form -auxbase-strip -O0 -fverbose-asm +// options passed: -ffixed-form -auxbase-strip -O1 -fverbose-asm +// -fno-loop-optimize -fno-tree-sra -fno-tree-ter -fno-omit-frame-pointer +// -fno-tree-dse -fno-tree-dominator-opts -fno-tree-ch -fno-tree-fre +// -fno-merge-constants -fno-cprop-registers -fno-if-conversion2 +// -fno-defer-pop -fno-tree-lrs -fno-guess-branch-probability -fno-tree-ccp +// -fno-tree-copyrename -fno-tree-dce -fno-if-conversion // options enabled: -falign-loops -fargument-noalias-global // -fbranch-count-reg -fcommon -feliminate-unused-debug-types // -ffunction-cse -fgcse-lm -fident -fivopts -fkeep-static-consts @@ -23,531 +28,280 @@ .prologue 14, 35 .save ar.pfs, r36 alloc r36 = ar.pfs, 3, 4, 2, 0 // + adds r16 = -8, r12 //,, .vframe r37 mov r37 = r12 //, - adds r12 = -80, r12 //,, + adds r12 = -32, r12 //,, + mov r17 = ar.lc //, + ;; + .savepsp ar.lc, 8 + st8 [r16] = r17, 8 //, mov r38 = r1//, As you can see from the fact that there is no differences in the options enabled: list in the assembly output, the assembly should be identical. However, the compilation results are very different, so -O1 seems to do other, undocumented things. $ cat ../dasum.f double precision function dasum(n,dx,incx) c c takes the sum of the absolute values. c jack dongarra, linpack, 3/11/78. c modified 3/93 to return if incx .le. 0. c modified 12/3/93, array(1) declarations changed to array(*) c double precision dx(*),dtemp integer i,incx,m,mp1,n,nincx c dasum = 0.0d0 dtemp = 0.0d0 if( n.le.0 .or. incx.le.0 )return if(incx.eq.1)go to 20 c ccode for increment not equal to 1 c nincx = n*incx do 10 i = 1,nincx,incx dtemp = dtemp + dabs(dx(i)) 10 continue dasum = dtemp return c ccode for increment equal to 1 c c cclean-up loop c 20 m = mod(n,6) if( m .eq. 0 ) go to 40 do 30 i = 1,m dtemp = dtemp + dabs(dx(i)) 30 continue if( n .lt. 6 ) go to 60 40 mp1 = m + 1 do 50 i = mp1,n,6 dtemp = dtemp + dabs(dx(i)) + dabs(dx(i + 1)) + dabs(dx(i + 2)) * + dabs(dx(i + 3)) + dabs(dx(i + 4)) + dabs(dx(i + 5)) 50 continue 60 dasum = dtemp return end -- Summary: options passed from -verbose-asm do not adequately reflect optimization Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19848
[Bug driver/19848] options passed from -verbose-asm do not adequately reflect optimization
-- What|Removed |Added OtherBugsDependingO||5900 nThis|| Version|unknown |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19848
[Bug fortran/5900] [g77 gfortran] Lapack regressions since g77 2.95.2
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-09 12:43 --- See PR 19848. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From joel at oarcorp dot com 2005-02-09 12:44 --- Subject: Re: gnat tools not buildable cross neroden at twcny dot rr dot com wrote: --- Additional Comments From neroden at twcny dot rr dot com 2005-02-09 07:13 --- Subject: Re: gnat tools not buildable cross joel at oarcorp dot com wrote: --- Additional Comments From joel at oarcorp dot com 2005-02-08 19:16 --- Subject: Re: gnat tools not buildable cross neroden at gcc dot gnu dot org wrote: --- Additional Comments From neroden at gcc dot gnu dot org 2005-02-08 18:30 --- Is a fix likely to get into 4.0? Yes, the hackish fix is in. I hope to get the cleaner fix in, but who knows. FYI Once I am able to build, the next issue is that the Ada libraries do not look into newlib's headers and do not have a way to let a target add specific include directories. See gcc/config/t-rtems for the OS specific newlib include directory we need. With that resolved, I think it could build in a single pass. I wouldn't want to touch this until substantially more of the branch went in, so that's probably a 4.1 issue. I need to get to test this first but I think the mistake in the gcc/ada/Makefile.in is actually quite simple. It has this: GNATLIBCFLAGS_FOR_C = $(GNATLIBCFLAGS) $(TARGET_LIBGCC2_CFLAGS) -fexceptions \ -DIN_RTS $(TARGET_LIBGCC2_CFLAGS) is not sufficient to find all the newlib headers. But the gcc/Makefile.in also uses $(LIBGCC2_INCLUDES) which is target specific when compiling libgcc2. LIBGCC2_INCLUDES is primarily set by RTEMS, VxWorks, and Cygwin. What do you think? Hmm. You could be right. :-) The trouble is that there's several layers of Makefiles and Makefile fragments and configures and configure fragments taking bits from each other, and so it's not as absolutely trivial to get LIBGCC2_INCLUDES in the right places cleanly -- without misapplying it in cross cases -- as it ought to be. This, of course, is what my cleanups are designed to fix; it *should* be trivial to get it in the right places. :-) I played with this overnight and the variable missing in ada/Makefile.in is FLAGS_FOR_TARGET. It shoudl be included in GNATLIBCFLAGS_FOR_C and I can't seem to get it from the top level configure all the way down. Do you have any idea how to get it down that far? --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug AWT/19849] New: Swing: ActionEvent.getActionCommand null
In order to avoid the overhead of individual event-listeners for every button or menu-item, my application uses a central ActionListener which uses ActionEvent.getActionCommand() to distinguish between the several (hundred) event sources. Unfortunately, ActionEvents created by Swing components in libgcj always return null for getActionCommand(). Testing with the JDKs (1.1 .. 5.0) reveals, that the JDKs return getText() for standard AbstractButtons like JButton or JMenuItem. I suggest that gcj also returns the value of getText() for these components. See attached testcase; compile and run with gcj and a JDK/JRE for comparison. -- Summary: Swing: ActionEvent.getActionCommand null Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: hendrich at informatik dot uni-hamburg dot de CC: fitzsim at redhat dot com,gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19849
[Bug AWT/19849] Swing: ActionEvent.getActionCommand null
--- Additional Comments From hendrich at informatik dot uni-hamburg dot de 2005-02-09 13:05 --- Created an attachment (id=8156) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8156action=view) testcase for the bug, run with gcj and java for comparison. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19849
[Bug libobjc/19850] New: libobjc leaks threads on posix
I just switched from gcc 2.95.x, where the GNUstep dox say I must use gnustep-objc, to gcc 3.3 where they say the built-in libobjc works fine. But it doesn't. It leaks threads, so eventually your program crashes in objc_detach_thread. The reason is that in gcc's libobjc, threads are created joinable, so when they exit they hang around forever waiting to be joined. In gthr-posix.h: if (!(pthread_create (new_thread_handle, NULL, (void *) func, arg))) the second argument to pthread_create is NULL, which means default attributes, which on linux 2.4 I believe means the threads are joinable, not detached. Now it looks like someone thought about this a bit because in the same gthr-posix.h there is a variable called _objc_thread_attribs initialized thusly: /* The normal default detach state for threads is * PTHREAD_CREATE_JOINABLE which causes threads to not die * when you think they should. */ if (pthread_attr_init (_objc_thread_attribs) == 0 pthread_attr_setdetachstate (_objc_thread_attribs, PTHREAD_CREATE_DETACHED) == 0) return 0; but _objc_thread_attribs, which you would think would be used as pthread_create's second argument, is in fact never used at all! Note that the thr-posix.c in gnustep-objc has nearly identical code that works -- it remembers to pass the _objc_thread_attribs in: if (!(pthread_create(new_thread_handle, _objc_thread_attribs, (void *)func, arg))) -- Summary: libobjc leaks threads on posix Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: libobjc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lcampbel at akamai dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19850
[Bug c++/17816] duplicate definition of pure virtual function not diagnosed
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-01-02 01:34:29 |2005-02-09 13:06:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17816
[Bug c++/18838] overload resolution depends on previous uses of the symbol
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-02-09 13:07 --- Err... Just tried this on mainline x86_64-linux-gnu and it didn't fail. Maybe it's fixed in mainline? It seems to be still broken in 3.4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18838
[Bug ada/19851] New: The new GNAT can't compile PolyORB
Hello, when compiling PolyORB with the HEAD release I get a bug box: +===GNAT BUG DETECTED==+ | 4.0.0 20050209 (experimental) (x86_64-unknown-linux-gnu) GCC error: | | in copy_tree_r, at tree-inline.c:2320| | Error detected at polyorb-binding_data-giop-diop.adb:131:8 | | 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. If you ask me to I will attach all those files - but I guess you know where to get PolyORB from ;-). I also made a little check on copy_tree_r and there is a new sanity check here: else if (TREE_CODE_CLASS (code) == tcc_type) *walk_subtrees = 0; else if (TREE_CODE_CLASS (code) == tcc_declaration) *walk_subtrees = 0; else if (TREE_CODE_CLASS (code) == tcc_constant) *walk_subtrees = 0; else gcc_assert (code != STATEMENT_LIST); With Regards Martin -- Summary: The new GNAT can't compile PolyORB Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: krischik at users dot sourceforge dot net CC: gcc-bugs 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=19851
[Bug ada/19851] The new GNAT can't compile PolyORB
--- Additional Comments From krischik at users dot sourceforge dot net 2005-02-09 13:11 --- Just forgot to mention: It's the same for classic 32 bit Linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19851
[Bug bootstrap/19852] New: Segmentation fault during: build/genmodes -h tmp-modes.h
Hello, I'm bootstrapping gcc (4.0.0 20050202) compiler on ibm aix 4.3.3. The bootstrap fails if genmodes runs. It aborts with segmentation fault. Is that a bug or does I something wrong??? My configure line is: CC=cc ar=/usr/bin/ar NM=/usr/bin/nm LD=/usr/bin/ld CONFIG_SHELL=/usr/local/bin/bash MAKE=/usr/local/bin/make /soft/gnu/packages/gcc_cvs/gcc/configure --prefix=/usr/local --without-libgcj --enable-languages=c,objc,c++ --with-ld=/usr/ccs/bin/ld --disable-nls Thanks Joerg Hundertmarck -- Summary: Segmentation fault during: build/genmodes -h tmp- modes.h Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hundertmarck at boehme-weihs dot de CC: gcc-bugs at gcc dot gnu dot org,hundertmarck at boehme- weihs dot de GCC build triplet: powerpc-ibm-aix4.3.3.0 GCC host triplet: powerpc-ibm-aix4.3.3.0 GCC target triplet: powerpc-ibm-aix4.3.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19852
[Bug java/8608] segmentation fault on compiling bad program
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-02-09 13:50 --- An ugly patch is here: http://gcc.gnu.org/ml/java-patches/2005-q1/msg00303.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8608
[Bug java/19841] Inner classes problem
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09
13:52 ---
Confirmed, here is a self contained example (which shows easier where the
problem is):
class T
{
private int state;
}
public class SSS {
int state = 0;
public class Selector extends T {
public void foo() {
state = 42;
}
}
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||rejects-valid
Last reconfirmed|-00-00 00:00:00 |2005-02-09 13:52:05
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19841
[Bug java/19841] Inner classes problem
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09 13:58 --- I looked and I don't see this as being a duplicate of the existing inner class bug reports. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19841
[Bug libgcj/15686] ^\ should print stack trace
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09 14:05 --- The signal is by the way: 3 QUIT (quit) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15686
[Bug tree-optimization/19853] New: [4.0 Regression] ICE with address in struct assignment
The following code ICEs at -O1 (this comes from
http://gcc.gnu.org/ml/gcc/2005-02/
msg00294.html:
struct test { int *x; } global_test;
int global_int;
int flag;
void test (char *dummy)
{
static const struct test const_test = { global_int };
struct test local_test;
int i;
for (i = 0; i 1; i++)
*dummy = 0;
if (flag)
__builtin_memset (dummy, 0, 16);
local_test = const_test;
global_test = local_test;
}
--
Summary: [4.0 Regression] ICE with address in struct assignment
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: critical
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19853
[Bug tree-optimization/19853] [4.0 Regression] ICE with address in struct assignment
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19853
[Bug tree-optimization/19854] [4.0 Regression] ICE with folding a[i1] + c * i2 to a[i1 + i2] messing up types
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09 14:24 --- I forgot to note this requires to be compiled with the C++ front-end. -- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19854
[Bug middle-end/19854] [4.0 Regression] ICE with folding a[i1] + c * i2 to a[i1 + i2] messing up types
-- What|Removed |Added Component|tree-optimization |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19854
[Bug middle-end/19854] [4.0 Regression] ICE with folding a[i1] + c * i2 to a[i1 + i2] messing up types
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-02-09 14:28 --- Patch in testing. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-09 14:28:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19854
[Bug c++/17816] duplicate definition of pure virtual function not diagnosed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09 14:36 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00351.html. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17816
[Bug tree-optimization/19853] [4.0 Regression] ICE with address in struct assignment
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09 14:38 --- Since this was just forwarding from the list and I can also confirm it, I am marking this as confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-09 14:38:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19853
[Bug c/19855] New: libconv error
On Solaris 9 (x86), after ./configure, make gcc 3.4.3 gives gcc -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-p rototypes -pedantic -Wno-long-long-DHAVE_CONFIG_H -o cc1 \ c-parse.o c-lang.o c-pretty-print.o stub-objc.o attribs.o c-errors.o c-l ex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o p refix.o c-objc-common.o c-dump.o c-pch.o libcpp.a main.o libbackend.a ../libibe rty/libiberty.a ../intl/libintl.a Undefined first referenced symbol in file libiconv_close libcpp.a(cppcharset.o) libiconv_open libcpp.a(cppcharset.o) libiconvlibcpp.a(cppcharset.o) ld: fatal: Symbol referencing errors. No output written to cc1 collect2: ld returned 1 exit status make[1]: *** [cc1] Error 1 make[1]: Leaving directory `/hoge/gcc-3.4.3/gcc' make: *** [all-gcc] Error 2 % -- Summary: libconv error Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: shanwill44 at yahoo dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19855
[Bug target/19597] [4.0 Regression] avr-gcc 4.0, multiplication by constant, very long code
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-09 14:43 --- Subject: Bug 19597 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-09 14:43:29 Modified files: gcc: ChangeLog gcc/config/avr : avr.c Log message: PR target/19597 * config/avr/avr.c (default_rtx_costs): Delete. (avr_operand_rtx_cost): New function. (avr_rtx_costs): Completely rewrite. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7419r2=2.7420 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/avr/avr.c.diff?cvsroot=gccr1=1.128r2=1.129 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19597
[Bug target/19597] [4.0 Regression] avr-gcc 4.0, multiplication by constant, very long code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09 14:49 --- Fixed for real this time. -- What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19597
[Bug c/19855] libconv error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09 14:52 --- *** This bug has been marked as a duplicate of 13307 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19855
[Bug bootstrap/13307] GCC will not build, stops in stage2 during libiconv call
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09 14:52 --- *** Bug 19855 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||shanwill44 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13307
[Bug libgcj/19823] java fails with non-executable memory
-- What|Removed |Added CC||aj at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19823
[Bug ada/19851] The new GNAT can't compile PolyORB
--- Additional Comments From charlet at gcc dot gnu dot org 2005-02-09 15:00 --- If you ask me to I will attach all those files - but I guess you know where to get PolyORB from ;-). All bugzilla reports should be self contained. The GCC project has no relationship with the PolyORB project, and PolyORB sources change very often, so it is really not conveninent to have to get a third party set of sources, and have to follow configure, ... set up steps. So please file self-contained and ready to use sources, thanks. Also, this bug is not critical, so lowering the priority. Arno -- What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19851
[Bug middle-end/19854] [4.0 Regression] ICE with folding a[i1] + c * i2 to a[i1 + i2] messing up types
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09 15:38 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00357.html. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19854
[Bug driver/19856] New: GCC_EXEC_PREFIX used wrong
GCC_EXEC_PREFIX behavior doesn't match the manual or reason and several ways. The manual says GCC_EXEC_PREFIX is a prefix for the program name, which means 'gcc' should look for 'cc1' as GCC_EXEC_PREFIX/cc1. But Strace indicates that 'gcc' looks at GCC_EXEC_PREFIX/MACHINE/VERSION/../../../.. MACHINE/bin/MACHINE/VERSION/cc1. This is a rather strange path. The manual says gcc looks using GCC_EXEC_PREFIX first, and then the usual places. That would be normal. For me, it looks in a bunch of places unrelated to GCC_EXEC_PREFIX, then the path described above, then gives up. The bunch of places mentioned above starts with something that is apparently based on the path by which 'gcc' was invoked, but has too many .. in it: MY_GCC_INSTALL_DIRECTORY/lib/../../lbiexec/gcc/MACHINE/VERSION/cc1. On the other hand, if I don't set GCC_EXEC_PREFIX, it properly looks at MY_GCC_INSTALL_DIRECTORY/bin/../libexec/gcc/MACHINE/VERSION/cc1. The manual says GCC_EXEC_PREFIX is used for finding subprograms and linker files, but it is apparently also used for the specs file -- GCC_EXEC_PREFIX/MACHINE/VERSION/specs . The manual says the default for GCC_EXEC_PREFIX is PREFIX/lib/gcc . But it also says when GCC_EXEC_PREFIX is not set, gcc searches based on the pathname with which it was invoked. The latter matches what the program does for me. (For clarity, I have written the above as if gcc add a slash after GCC_EXEC_PREFIX; as documented, it doesn't). Note that in these experiments, I built gcc with PREFIX = nonexistent directory to ensure no built-in path gets used. Finally, if someone works on the manual section, I highly recommend moving the environment variable section out of the Gcc Command Options section. It doesn't fit there; I had a hard time finding it. -- Summary: GCC_EXEC_PREFIX used wrong Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bryanh at giraffe-data dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19856
[Bug c/19857] New: alignment check of SSE constant fails in simple test program
When I compile a simple test program that declares an SSE constant and checks
that it is 8-byte aligned (see below), the alignment check fails in the
gcc 4.0 snapshot (it succeeds in 3.3.5).
I'm not sure whether the constant is actually misaligned or the alignment
check itself is miscompiled...changing the check slightly makes it succeed.
Environment:
System: Linux fftw.org 2.6.3-1-686-smp #2 SMP Tue Feb 24 20:29:08 EST 2004 i686
GNU/Linux
Architecture: i686
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../configure --prefix=/home/stevenj/gcc4
How-To-Repeat:
Compile the following code with 'gcc -O3 -msse -o bug bug.c' and run
with './bug echo ok' ... output *should* be ok (ALIGNED==true),
but is not.
(Yes, the way the alignment check is performed looks kinda weird...it
is distilled from other code (www.fftw.org), obviously...but it should
still pass for any 8-byte aligned quantity.)
Thanks for looking into this,
Steven G. Johnson
typedef float V __attribute__ ((vector_size (16)));
union fvec {
float f[4];
V v;
};
typedef unsigned int uintptr_t;
#define ALIGNMENT 8
#define TAINT_BIT 1
#define UNTAINT(p) ((float *) (((uintptr_t) (p)) ~(uintptr_t)3))
#define PTRINT(p) ((uintptr_t)(p))
#define ALIGNED(p) \
(((PTRINT(UNTAINT(p)) % ALIGNMENT) == 0) !(PTRINT(p) TAINT_BIT))
const union fvec foo = {{-0.0, 0.0, -0.0, 0.0}};
int main(void)
{
return !ALIGNED(foo);
}
--
Summary: alignment check of SSE constant fails in simple test
program
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stevenj at fftw dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19857
[Bug driver/19856] GCC_EXEC_PREFIX used wrong
--- Additional Comments From bryanh at giraffe-data dot com 2005-02-09 17:06 --- Created an attachment (id=8157) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8157action=view) strace of failure to find cc1 In this run, PREFIX is /home/bryanh/gcc . GCC_EXEC_PREFIX is /tmp2/gcc-3.4.3/lib/gcc// . /tmp2 is a symlink to /mp/hdb2 . Gcc, in the form created by 'make install', is installed in /tmp2/gcc-3.4.3 -- i.e. 'make install' created the tree at /home/bryanh/gcc and I moved it to /tmp2/gcc-3.4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19856
[Bug c/19858] New: ICE on simple SSE code (works in gcc 3.3)
The code below, when compiled by gcc -O3 -msse, gives the following
error (same code compiles fine in gcc 3.3.5):
bug2.c: In function 'main':
bug2.c:17: error: Invalid reference prefix.
fooD.1292;
bug2.c:17: internal compiler error: verify_stmts failed.
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
Environment:
System: Linux fftw.org 2.6.3-1-686-smp #2 SMP Tue Feb 24 20:29:08 EST 2004 i686
GNU/Linux
Architecture: i686
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../configure --prefix=/home/stevenj/gcc4
How-To-Repeat:
Compile the following code with 'gcc -O3 -msse -o bug2 bug2.c'
typedef float V __attribute__ ((vector_size (16)));
union fvec {
float f[4];
V v;
};
typedef unsigned int uintptr_t;
#define ALIGNMENT 8
#define TAINT_BIT 1
#define PTRINT(p) ((uintptr_t)(p))
#define ALIGNED(p) \
(((PTRINT(p) % ALIGNMENT) == 0) !(PTRINT(p) TAINT_BIT))
const union fvec foo = {{-0.0, 0.0, -0.0, 0.0}};
int main(void)
{
return !ALIGNED(foo);
}
--
Summary: ICE on simple SSE code (works in gcc 3.3)
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stevenj at fftw dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19858
[Bug target/19859] New: SImode and DImode usage
The c4x target does not build any more because a lot of code uses SImode and DImode for 32 and 64 bit values. This is incorrect for the c4x target because here QImode is 32 bits and HImode is 64 bits (chars/ints/longs = 32 bits, long long = 64 bits). I did a quick search on the current (20050209) version and found about 113 problems. The problems are listed below. I am not sure the list is complete but it is a start. I the past some changes were made for example to libgcc2.h, gcov-io.h. Also for SImode one can write TYPE_MODE (integer_type_node). The same can be done for DImode. The list of files+linenumbers: /libffi/include/ffi_common.h:81:typedef unsigned int UINT32 __attribute__((__mode__(__SI__))); ./libffi/include/ffi_common.h:82:typedef signed int SINT32 __attribute__((__mode__(__SI__))); ./libffi/include/ffi_common.h:83:typedef unsigned int UINT64 __attribute__((__mode__(__DI__))); ./libffi/include/ffi_common.h:84:typedef signed int SINT64 __attribute__((__mode__(__DI__))); ./libffi/src/mips/ffitarget.h:128:typedef unsigned int ffi_arg __attribute__((__mode__(__SI__))); ./libffi/src/mips/ffitarget.h:129:typedef signed int ffi_sarg __attribute__((__mode__(__SI__))); ./libffi/src/mips/ffitarget.h:132:typedef unsigned int ffi_arg __attribute__((__mode__(__DI__))); ./libffi/src/mips/ffitarget.h:133:typedef signed int ffi_sarg __attribute__((__mode__(__DI__))); ./libffi/src/ia64/ffi.c:39:typedef void *PTR64 __attribute__((mode(DI))); ./libjava/gcj/javaprims.h:510:typedef unsigned int _Jv_uint __attribute__((__mode__(__SI__))); ./libjava/gcj/javaprims.h:511:typedef unsigned int _Jv_ulong __attribute__((__mode__(__DI__))); ./libjava/include/jni.h:52:typedef intjint __attribute__((__mode__(__SI__))); ./libjava/include/jni.h:53:typedef intjlong __attribute__((__mode__(__DI__))); ./libjava/java/lang/mprec.h:61:// FIXME -- this could have problems with systems that don't define SI to be 4 ./libjava/java/lang/mprec.h:62:typedef int int32_t __attribute__((mode(SI))); ./libjava/java/lang/mprec.h:68:typedef unsigned int uint32_t __attribute__((mode(SI))); ./libjava/gnu/gcj/io/shs.h:29:typedef unsigned int uint32_t __attribute__((mode(SI))); ./gcc/expr.c:8715: enum machine_mode index_mode = SImode; ./gcc/loop.c:768: reg_address_cost = address_cost (reg, SImode); ./gcc/unwind-dw2.c:86: unsigned u4 __attribute__ ((mode (SI))); ./gcc/unwind-dw2.c:87: unsigned u8 __attribute__ ((mode (DI))); ./gcc/unwind-dw2.c:89: signed s4 __attribute__ ((mode (SI))); ./gcc/unwind-dw2.c:90: signed s8 __attribute__ ((mode (DI))); ./gcc/tree.c:5683: intSI_type_node = make_or_reuse_type (GET_MODE_BITSIZE (SImode), 0); ./gcc/tree.c:5684: intDI_type_node = make_or_reuse_type (GET_MODE_BITSIZE (DImode), 0); ./gcc/tree.c:5689: unsigned_intSI_type_node = make_or_reuse_type (GET_MODE_BITSIZE (SImode), 1); ./gcc/tree.c:5690: unsigned_intDI_type_node = make_or_reuse_type (GET_MODE_BITSIZE (DImode), 1); ./gcc/coverage.c:605: fields = build_decl (FIELD_DECL, NULL_TREE, unsigned_intSI_type_node); ./gcc/coverage.c:608: field = build_decl (FIELD_DECL, NULL_TREE, unsigned_intSI_type_node); ./gcc/coverage.c:639: value = tree_cons (fields, build_int_cstu (unsigned_intSI_type_node, ./gcc/coverage.c:644: value = tree_cons (fields, build_int_cstu (unsigned_intSI_type_node, ./gcc/coverage.c:677: field = build_decl (FIELD_DECL, NULL_TREE, unsigned_intSI_type_node); ./gcc/coverage.c:714:build_int_cstu (unsigned_intSI_type_node, ./gcc/coverage.c:788: field = build_decl (FIELD_DECL, NULL_TREE, unsigned_intSI_type_node); ./gcc/coverage.c:791: value = tree_cons (field, build_int_cstu (unsigned_intSI_type_node, ./gcc/coverage.c:801: field = build_decl (FIELD_DECL, NULL_TREE, unsigned_intSI_type_node); ./gcc/coverage.c:804: value = tree_cons (field, build_int_cstu (unsigned_intSI_type_node, ./gcc/loop-unswitch.c:237: stest = simplify_gen_relational (GET_CODE (test), SImode, ./gcc/loop-unswitch.c:243: return canon_condition (gen_rtx_fmt_ee (GET_CODE (test), SImode, ./gcc/optabs.c:704: tmp = simplify_relational_operation (cmp_code, SImode, op1_mode, cmp1, cmp2); ./gcc/optabs.c:4403: if (GET_MODE_SIZE (GET_MODE (from)) GET_MODE_SIZE (SImode)) ./gcc/optabs.c:4404:from = convert_to_mode (SImode, from, unsignedp); ./gcc/optabs.c:4580: if (GET_MODE_SIZE (GET_MODE (to)) GET_MODE_SIZE (SImode)) ./gcc/optabs.c:4582: target = gen_reg_rtx (SImode); ./gcc/cfgloopanal.c:515: rtx reg1 = gen_raw_REG (SImode, FIRST_PSEUDO_REGISTER); ./gcc/cfgloopanal.c:516: rtx reg2 = gen_raw_REG (SImode, FIRST_PSEUDO_REGISTER + 1); ./gcc/cfgloopanal.c:518: rtx mem = validize_mem (gen_rtx_MEM (SImode, addr)); ./gcc/loop-iv.c:1597: || GET_MODE (cond) != SImode) ./gcc/loop-iv.c:1598:cond = gen_rtx_fmt_ee (code, SImode, op0, op1); ./gcc/loop-iv.c:1842: cond_under = simplify_gen_relational (LT, SImode, iv-extend_mode, ./gcc/loop-iv.c:1844: cond_over = simplify_gen_relational (GT, SImode, iv
[Bug c++/18838] overload resolution depends on previous uses of the symbol
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2004-12-05 01:33:21 |2005-02-09 17:21:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18838
[Bug c++/17788] poor diagnostic for missing reference initializer
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-01-02 01:08:42 |2005-02-09 17:21:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17788
[Bug AWT/19860] New: Swing JOptionPane and multiline texts
JOptionPane fails to render multiline text in the 'standard' dialogs.
Testcase attached; tested with gcc-4.0-20050130 snapshot and current
gui-branch-20040128 cvs.
(the location of the JButtons is sub-optimal, too.)
/* MultilineJOptionPane.java
*
* demonstrates GCJ doesn't display multiple lines of text in a JOptionPane
*
* (C) 2005 FNH
*/
import java.awt.*;
import javax.swing.*;
public class MultilineJOptionPane {
public static void main( String args[] ) {
JFrame frame = new JFrame( just a frame );
frame.setSize(50,50);
frame.show();
String s =
The first line of text, five to follow...\n
+ A second line of text,\n
+ and the third,\n
+ fourth,\n
+ and fifth line of text. Click ok to exit.\n
;
JOptionPane.showMessageDialog( frame, s );
System.exit( 0 );
}
}
--
Summary: Swing JOptionPane and multiline texts
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: AWT
AssignedTo: fitzsim at redhat dot com
ReportedBy: hendrich at informatik dot uni-hamburg dot de
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19860
[Bug AWT/19861] New: Swing JOptionPane without parent frame
The following testcase shows a (subtle) problem in the Swing rendering strategy.
A JOptionPane dialog without any parent works fine, but a JOptionPane
attached to a non-showing parent (e.g. JFrame) fails with an
IllegalComponentStateException. Because the Exception blocks the Swing
redraw thread, there is no way to recover from the illegal state.
(both dialog windows work fine under JDK 1.4.2, not tested with other versions).
/* NoParentJOptionPane.java
*
* demonstrates GCJ doesn't like dialogs without visible parents...
*
* (C) 2005 FNH
*/
import java.awt.*;
import javax.swing.*;
public class NoParentJOptionPane {
public static void main( String args[] ) {
String s = Testing JOptionPane w/o parent...;
System.out.println( The first call works: null parent: );
JOptionPane.showMessageDialog( null, s );
// JDK1.4+ runs this, gcj complains about:
// java.awt.IllegalComponentStateException: component not showing
// at java.awt.Component.getLocationOnScreen()
// at javax.swing.SwingUtilities.convertPointToScreen(java.awt.Point,
java.awt.Component)
// at javax.swing.SwingUtilities.convertPoint(java.awt.Component, int, int,
java.awt.Component) (/usr/lib/lib-javax-swing.so.0.0.0)
// ...
JFrame frame = new JFrame( just a hidden frame );
System.out.println( The second call is broken: frame parent );
JOptionPane.showMessageDialog( frame, s );
System.exit( 0 );
}
}
--
Summary: Swing JOptionPane without parent frame
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: AWT
AssignedTo: fitzsim at redhat dot com
ReportedBy: hendrich at informatik dot uni-hamburg dot de
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19861
[Bug AWT/19862] New: Swing JTextField fails with StringIndexOutOfBoundsException
Entering text into a JTextField fails with an StringIndexOutOfBoundsException, triggered by a problem in GapContent or AbstractDocument.getText(). Tested with gcc-4.0-20050130 snapshot and a current (2005.02.09) cvs checkout of gui-branch-20040128: java.lang.StringIndexOutOfBoundsException at java.lang.StringBuffer.substring(int, int) (/usr/lib/libgcj.so.6.0.0) at javax.swing.text.GapContent.getString(int, int) (/usr/lib/lib-javax-swing.so.0.0.0) at javax.swing.text.AbstractDocument.getText(int, int) (/usr/lib/lib-javax-swing.so.0.0.0) at javax.swing.text.FieldView.getPreferredSpan(int) (/usr/lib/lib-javax-swing.so.0.0.0) Testcase attached. Note that the calculator functionality is stripped off to make the testcase shorter. (This is slightly unfair for gcj, because the expression parser does work with gcj.) -- Summary: Swing JTextField fails with StringIndexOutOfBoundsException Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: hendrich at informatik dot uni-hamburg dot de CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19862
[Bug AWT/19862] Swing JTextField fails with StringIndexOutOfBoundsException
--- Additional Comments From hendrich at informatik dot uni-hamburg dot de 2005-02-09 17:43 --- Created an attachment (id=8158) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8158action=view) testcase Just compile the class, then try entering an expression into the JTextField on the bottom of the main window and press return or press the Execute button. Note that the program also triggers a few other bugs; it can be tricky to tranfer the keyboard focus to the textfield in the first place -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19862
[Bug SWING/19863] New: Swing JMenus appear at wrong locations
On my computer, JMenus and especially nested JMenus appear on wrong locations, sometimes shifted right across the screen. Tested with gcc-4.0-20050130 snapshot and current cvs gui-branch-20050128 checkout (as of 2005.02.09). Note: this problem may be WindowManager dependent; I used ctwm on XFree 4.3. Testcase: please compile and run the program I submitted for bug 19862 (InteractiveCalculator.java) and try the menus. The problem also concerns JPopupMenus, for a testcase see the program I attached to http://gcc.gnu.org/ml/java/2005-02/msg00016.html. -- Summary: Swing JMenus appear at wrong locations Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: SWING AssignedTo: graydon at redhat dot com ReportedBy: hendrich at informatik dot uni-hamburg dot de CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19863
[Bug libgcj/19864] New: DomLSEx should use ordinary chaining
The DomLSEx class has two bugs: First, it is named poorly. There's no reason not to spell out Exception, like the rest of java. Second, it has its own chaining approach. It should simply use the chaining built into the core. -- Summary: DomLSEx should use ordinary chaining Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19864
[Bug ada/19865] New: ice / gnat bug detected.
../../xgcc -c -I./ -I../rts -I. -I/home/users/builder2/devel/pld/sandbox/gcc/BUILD/gcc-4.0-20050130/gcc/ada -B../../ -O2 -O2 -fsigned-char -gnatpg -gnata -I- /home/users/builder2/devel/pld/sandbox/gcc/BUILD/gcc-4.0-20050130/gcc/ada/m akegpr.adb gnat1: warning: command line option -fsigned-char is valid for C/C++/ObjC/ObjC++ but not for Ada+ ===GNAT BUG DETECTED==+| 4.0.0 20050130 (experimental) (PLD Linux) (powerpc-pld-linux-gnu) GCC error: tree check: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:680 Error detected at makegpr.adb:4167:23 -- Summary: ice / gnat bug detected. Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at pld-linux dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: ppc-pld-linux GCC host triplet: ppc-pld-linux GCC target triplet: ppc-pld-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19865
[Bug c/19866] New: Conversion from type ** to const type ** issues a warning.
Example program test.c:
void foo(const void **bar) {
}
int main() {
void **bar = 0;
foo(bar);
}
Compilation with gcc test.c:
test.c:6: warning: passing arg 1 of `foo' from incompatible pointer type.
Expected result: compilation without any warning at all.
Using pointers to pointers, it happens always.
gcc -v:
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.1/specs
Configured with: ../gcc-3.4.1/configure --prefix=/usr --libexecdir=/usr/lib
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-languages=c,c++,objc,f77,ada,java
Thread model: posix
gcc version 3.4.1
--
Summary: Conversion from type ** to const type ** issues a
warning.
Product: gcc
Version: 3.4.1
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jorgleis at in-exedra dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19866
[Bug libgcj/19823] java fails with non-executable memory
--- Additional Comments From aj at gcc dot gnu dot org 2005-02-09 18:27 --- I looked at my build dir (4.0 CVS) and everything looks ok. I guess I should run some strace - could somebody tell me how to invoke gij from the commandline in a simple case so that I can check this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19823
[Bug c++/18838] [3.4 only] overload resolution depends on previous uses of the symbol
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09 18:31 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00370.html. -- What|Removed |Added Keywords||patch Known to fail|3.3.5 3.4.3 4.0.0 |3.3.5 3.4.3 Known to work||4.0.0 Summary|overload resolution depends |[3.4 only] overload |on previous uses of the |resolution depends on |symbol |previous uses of the symbol Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18838
[Bug middle-end/19854] [4.0 Regression] ICE with folding a[i1] + c * i2 to a[i1 + i2] messing up types
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09 18:37 --- Fixed by: 2005-02-09 Richard Guenther [EMAIL PROTECTED] PR middle-end/19854 * fold-const.c (try_move_mult_to_index): Remove redundant type argument. Create ADDR_EXPR with correct type. (fold): Update callers of try_move_mult_to_index. Convert result to the appropriate type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19854
[Bug middle-end/19854] [4.0 Regression] ICE with folding a[i1] + c * i2 to a[i1 + i2] messing up types
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-02-09 18:40 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19854
[Bug driver/19856] GCC_EXEC_PREFIX used wrong
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09 19:07 --- I think this related to PR 14435. But reading the docs (there is a section in there which is useful to read): In addition, the prefix is used in an unusual way in finding the directories to search for header files. For each of the standard directories whose name normally begins with /usr/local/lib/gcc (more precisely, with the value of GCC_INCLUDE_DIR), GCC tries replacing that beginning with the specified prefix to produce an alternate directory name. Thus, with -Bfoo/, GCC will search foo/bar where it would normally search /usr/local/lib/bar. These alternate directories are searched first; the standard directories come next. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19856
[Bug ada/19865] ice / gnat bug detected.
-- What|Removed |Added CC||mmazur at kernel dot pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19865
[Bug c++/18418] [3.4 only] GCC 3.4.3 builds worse code than GCC 3.3.4 using template expressions
--- Additional Comments From bangerth at dealii dot org 2005-02-09 19:24 --- There's also other stuff lurking in assembler files, such as a lot of notes for labels. These aren't code, and I've seen cases where newer compilers output more labels than older ones for some reason. Unless you show us some run-time comparisons, I guess there isn't much willingness here to do something about it. I'll put this PR into waiting state. Thanks Wolfgang -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18418
[Bug tree-optimization/18441] Vectorizer: add a command line for simple vectorizer report
--- Additional Comments From dorit at il dot ibm dot com 2005-02-09 19:30 --- continued in this thread: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00196.html and cmmitted: http://gcc.gnu.org/ml/gcc-cvs/2005-02/msg00153.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18441
[Bug libstdc++/19867] New: ext/array_allocator/2.cc test failure in __exchange_and_add
libstdc++ test ext/array_allocator/2.cc has failed for powerpc*-*-linux* since it was added on 2004-10-07. On powerpc64-unknown-linux-gnu for both -m32 and -m64 it gets SIGBUS in __exchange_and_add from atomicity.cc during a destructor call. The test passes on AIX and Darwin, which use the same atomicity.h file, but all archived test results for powerpc*-*-linux* show the failure. It seems to fail intermittently on powerpc-unknown-eabispe. -- Summary: ext/array_allocator/2.cc test failure in __exchange_and_add Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: powerpc*-*-linux* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19867
[Bug middle-end/19858] [4.0 Regression] ICE on simple SSE code (works in gcc 3.3)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09
19:35 ---
Confirmed, this is werid, what are the sematics of BIT_FIELD_REF.
Here is the reduced testcase:
union fvec { };
typedef __SIZE_TYPE__ uintptr_t;
union fvec foo;
int main(void)
{
return !(uintptr_t)(foo)) 3 ) == 0) !(((uintptr_t)(foo)) 1));
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c |middle-end
Ever Confirmed||1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2005-02-09 19:35:38
date||
Summary|ICE on simple SSE code |[4.0 Regression] ICE on
|(works in gcc 3.3) |simple SSE code (works in
||gcc 3.3)
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19858
[Bug libstdc++/19867] ext/array_allocator/2.cc test failure in __exchange_and_add
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09 19:38 --- BJE already filed a bug for this and there is more details in that bug. See PR 19495 which I am close this as a dup of. *** This bug has been marked as a duplicate of 19495 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19867
[Bug libstdc++/19495] basic_string::_M_rep() can produce an unnaturally aligned pointer to _Rep
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09 19:38 --- *** Bug 19867 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495
[Bug libobjc/19850] libobjc leaks threads on posix
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09 19:42 --- Confirmed. I will try to have this fixed for 4.1 but no promises. Basically it is gthr-posix.c is out of step from thr-posix.c -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-09 19:42:56 date|| Version|unknown |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19850
[Bug driver/19856] GCC_EXEC_PREFIX used wrong
--- Additional Comments From bryanh at giraffe-data dot com 2005-02-09 19:43 --- Subject: Re: GCC_EXEC_PREFIX used wrong I don't see the relevance of that paragraph to either of the problem reports, since there is no search for header files involved. I don't know anything about the Gcc bug fixing process, but I see that PR 14435 is 11 months old. Has anything been changed because of it? Will it be? If code or doc needs to be written, I'd be happy to do it, but if someone else has to figure out what GCC_EXEC_PREFIX should do, that would be premature. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19856
[Bug regression/19857] [4.0 Regression alignment check of SSE constant fails in simple test program
-- What|Removed |Added Severity|critical|normal Component|c |regression Keywords||wrong-code Summary|alignment check of SSE |[4.0 Regression alignment |constant fails in simple|check of SSE constant fails |test program|in simple test program Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19857
[Bug regression/19857] [4.0 Regression] alignment check of SSE constant fails in simple test program
-- What|Removed |Added Summary|[4.0 Regression alignment |[4.0 Regression] alignment |check of SSE constant fails |check of SSE constant fails |in simple test program |in simple test program http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19857
[Bug target/19537] tic4x does not build -- ICE in libgcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09 19:46 --- *** Bug 19859 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||hermantenbrugge at home dot ||nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19537
[Bug target/19859] SImode and DImode usage
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09 19:46 --- *** This bug has been marked as a duplicate of 19537 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19859
[Bug ada/19865] [4.0 Regression] ice / gnat bug detected.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09 19:47 --- Confirmed. -- What|Removed |Added BugsThisDependsOn||19853 Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-02-09 19:47:29 date|| Summary|ice / gnat bug detected.|[4.0 Regression] ice / gnat ||bug detected. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19865
[Bug c/19866] Conversion from type ** to const type ** issues a warning.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09 19:51 --- The warning is correct. const void ** is not compatiable to void **, the const binds to the void but since only const void * and void * are compatible but not type* and type1*. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19866
[Bug c++/19868] New: error for legal friend statement ?
Hello there,
Give the following C++ code
class A
{
private:
void f();
};
class B
{
private:
friend void A :: f();
};
then g++ 3.4.2 and g++ 3.4 snapshot 20050128 say
[EMAIL PROTECTED] Alphasrc]$ ~/gnu/20050128/results/bin/g++ -c friend2.cc
friend2.cc:5: error: `void A::f()' is private
friend2.cc:11: error: within this context
I checked a couple of other C++ compilers, and they were happy with
the code.
I checked Stroustrup 3, section 11.5, page 279 in my copy. He has similar
code, and he appears to claim that the code should be ok.
Would I be correct in thinking that the definition of the language has
recently changed in this area ?
--
Summary: error for legal friend statement ?
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: linux-i686-pc-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19868
[Bug libgcj/19823] java fails with non-executable memory
--- Additional Comments From tromey at gcc dot gnu dot org 2005-02-09 20:09 --- I'm not so sure that the patch to always define USE_MMAP really has that effect. By my reading this patch is revision 1.36, but if you diff against 1.35 and then go look at include/private/gcconfig.h, it looks like this addition takes place in the middle of a big #ifdef M68K. Am I misreading this? I have no explanation of why things work on my system. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19823
[Bug c++/19868] error for legal friend statement ?
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09 20:13 --- Nope the code is invalid and looks like most compilers get it wrong also then. This is a dup of bug 7809. This was also DR 209. *** This bug has been marked as a duplicate of 7809 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19868
[Bug c++/7809] befriending inaccessible names
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-09 20:13 --- *** Bug 19868 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||dcb314 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7809
[Bug target/18251] unable to find a register to spill in class `POINTER_REGS'
--- Additional Comments From bjoern dot m dot haase at web dot de
2005-02-09 20:27 ---
The bug seems still to be present in head 4.0.0.
The failing example could be stripped down a little bit further:
// Begin of sample code
unsigned long semaphore_create (unsigned long name,
unsigned long count,
unsigned long attribute_set,
unsigned long *id
);
struct termios
{
unsigned int c_iflag;
unsigned int c_oflag;
unsigned int c_cflag;
unsigned int c_lflag;
unsigned char c_cc[19];
};
typedef struct termios_callbacks
{
int (*firstOpen) (int major, int minor, void *arg);
int (*lastClose) (int major, int minor, void *arg);
int (*pollRead) (int minor);
} termios_callbacks;
void *calloc (unsigned int __nmemb, unsigned int __size);
struct termios_rawbuf
{
char *theBuf;
int Head;
int Tail;
int Size;
int Semaphore;
};
struct termios_tty
{
struct termios_tty *forw;
struct termios_tty *back;
unsigned long major;
unsigned long minor;
unsigned long isem;
unsigned long osem;
char *cbuf;
int ccount;
int cindex;
int column;
int read_start_column;
struct termios termios;
struct termios_rawbuf rawInBuf;
struct termios_rawbuf rawOutBuf;
termios_callbacks device;
unsigned int flow_ctrl;
unsigned int lowwater, highwater;
unsigned int rxTaskId;
unsigned int txTaskId;
int tty_rcvwakeup;
};
unsigned long
termios_open (unsigned long major,
unsigned long minor,
struct termios_tty *tty,
const termios_callbacks * callbacks)
{
unsigned long sc;
{
tty = calloc (1,0);
if (tty == ((void *) 0))
return 0;
tty-rawInBuf.Size = 128;
tty-minor = minor;
tty-major = major;
sc = semaphore_create (0, 1, 0, 0 );
tty-device = *callbacks;
tty-lowwater = tty-rawInBuf.Size * 1 / 2;
}
}
// End of sample code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251
