--- Comment #6 from wt at simpack dot de 2007-03-09 07:39 ---
guys, is absolutely agree that what g95 does is of no concern here.
However the problems we are experienceing are with gfortran (the link attached
in the previous statement contained info about both gfortran and g95).
when ty
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2007-03-09 07:37
---
hmm, I goofed, the patch in #14 does not fix this, scratch that. However, the
problem is that test_endfile in st_rewind is incorrectly setting the AT_ENDFILE
condition. I have a patch in progress.
--
http:
--- Comment #1 from christian dot joensson at gmail dot com 2007-03-09
07:36 ---
One the same computer system, this also happens on trunk, ie. 4.3.0...
LAST_UPDATED: Wed Mar 7 11:15:23 UTC 2007 (revision 122655)
Executing on host: /usr/local/src/trunk/objdir/gcc/testsuite/g++/../../
http://gcc.gnu.org/ml/fortran/2007-02/msg00167.html
> > > From what I've seen, one of the main problems with Fortran and
> > > aliasing is the pass-by-reference rule in Fortran. This often tricks
> > > alias analysis into overstating the amount of call-clobbered variables.
> > Can we do something
--- Comment #8 from patchapp at dberlin dot org 2007-03-09 06:50 ---
Subject: Bug number PR30643
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00525.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #2 from pault at gcc dot gnu dot org 2007-03-09 05:14 ---
(In reply to comment #1)
> Please submit a full bug report,
>
Confirmed.
Daniel, A temporary workaround is to eliminate the USE class_dummy_atom_types's
in the subroutines and to promote them to module level or n
--- Comment #1 from bangerth at dealii dot org 2007-03-09 05:05 ---
This appears to work on x86 linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31092
--- Comment #1 from bangerth at dealii dot org 2007-03-09 05:01 ---
Confirmed, though I believe this is a duplicate of some other PR. This
is not a regression.
Somewhat smaller:
--
template class C {};
template
class X
{
static const unsigned int Value = 2;
--- Comment #4 from bangerth at dealii dot org 2007-03-09 04:54 ---
Confirmed. This is a regression introduced in 4.0.x.
Somewhat shorter:
struct A {};
template
struct C: virtual A {
C() {};
template C(const C&) {};
C func(const class C&) const;
operato
--- Comment #11 from brooks at gcc dot gnu dot org 2007-03-09 04:51 ---
Created an attachment (id=13175)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13175&action=view)
Fixincludes patch to fix _mingw.h.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
--- Comment #10 from brooks at gcc dot gnu dot org 2007-03-09 04:50 ---
See http://gcc.gnu.org/ml/fortran/2007-03/msg00155.html for a proposed patch.
I'll attach it here, as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
--- Comment #2 from bangerth at dealii dot org 2007-03-09 04:46 ---
Confirmed. This is a regression introduced in gcc4.0.x. Since the
error message doesn't give any context except for the ICE, I rate this
as somewhat more than a nuisance.
W.
--
bangerth at dealii dot org changed:
--- Comment #2 from bangerth at dealii dot org 2007-03-09 04:43 ---
Confirmed. The message is probably ok, except that the code that dumps
a tree can't deal with some of the codes in it.
W.
--
bangerth at dealii dot org changed:
What|Removed |Adde
--- Comment #4 from bangerth at dealii dot org 2007-03-09 04:40 ---
What exactly are you trying to achieve here:
-
typedef void (B::*FPTR)(int);
...
struct C : public A , public B {
virtual void C_bad() { }
};
c.t((FPTR)&C::C_bad);
--
Clearly, C::Cba
--- Comment #3 from bangerth at dealii dot org 2007-03-09 04:34 ---
(In reply to comment #0)
Take a look at this again:
> struct A
> {
> operator short& () { return m_value; }
> operator short () const { return m_value; }
> };
>
> const A CONSTA(-1);
>
> struct
--- Comment #1 from bangerth at dealii dot org 2007-03-09 04:22 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC|
--- Comment #1 from bangerth at dealii dot org 2007-03-09 04:21 ---
Confirmed. Not a regression.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2007-03-09 04:20 ---
We got a warning in gcc2.95, but it has apparently already disappeared in
gcc3.2.x.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
-
--- Comment #1 from bangerth at dealii dot org 2007-03-09 04:16 ---
Confirmed.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from bangerth at dealii dot org 2007-03-09 04:14 ---
Here's a reduced code:
-
struct cons_end {};
template struct cons {
U elem;
V tail;
};
template
void foo(U elem, V tail)
{
foo(tail.elem,tail.tail);
}
template
void foo(U elem, cons_end tail)
--- Comment #2 from schnetter at aei dot mpg dot de 2007-03-09 03:51
---
After an svn update and a full bootstrap, it still breaks for me for gcc (GCC)
4.3.0 20070308, svn revision 122699.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31076
--- Comment #1 from bangerth at dealii dot org 2007-03-09 03:47 ---
I oppose this change in existing behavior. People have all sorts of
testsuites where existing behavior is stored in output files and
compared against every night. A change in such behavior may lead
to lots of unnecessar
--- Comment #5 from bangerth at dealii dot org 2007-03-09 03:43 ---
If you make it defined earlier than the standard says, then you
get into trouble for cases like this:
void f() {
struct X {
void g(const char * = __FUNCTION__) {}
};
}
According to the N1970, this ref
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-03-09 02:50
---
Subject: Bug 31072
Author: pinskia
Date: Fri Mar 9 02:50:22 2007
New Revision: 122739
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122739
Log:
2007-03-08 Andrew Pinski <[EMAIL PROTECTED]>
PR
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-03-09 02:50
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-09 00:50 ---
In reference to the triplets question, refer next time to
http://gcc.gnu.org/bugs.html
Which tells you how to file a bug report.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31083
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-03-09 00:32
---
Fixed on the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-03-09 00:32 ---
Subject: Bug 31072
Author: pinskia
Date: Fri Mar 9 00:32:34 2007
New Revision: 122736
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122736
Log:
2007-03-08 Andrew Pinski <[EMAIL PROTECTED]>
PR C/
--- Comment #7 from fang at csl dot cornell dot edu 2007-03-08 23:41
---
Subject: Re: Overloaded operator delete[] doesn't get called
> Above, in operator new[], If WTF is false, returning NULL, I reproduce the
> same error (missing call to class operator delete []). If WTF is true
>
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-08 23:38 ---
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00481.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28002
--- Comment #2 from tromey at gcc dot gnu dot org 2007-03-08 22:59 ---
With svn trunk and also the fc6 libgcj I get:
opsy. gij PromiscuousTrafficTester
Listening on address /229.10.11.12
Listening on address /229.10.11.13
Sending 'Hello' on /229.10.11.12:64000
java.lang.IllegalStateExce
--- Comment #6 from fang at csl dot cornell dot edu 2007-03-08 22:58
---
Subject: Re: Overloaded operator delete[] doesn't get called
This following test case is 'interesting':
>8 snip 8<-
#include
using std::cout;
class one_array_only {
private:
--- Comment #5 from rakdver at gcc dot gnu dot org 2007-03-08 22:37 ---
Fixed.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from rakdver at gcc dot gnu dot org 2007-03-08 22:36 ---
Subject: Bug 31085
Author: rakdver
Date: Thu Mar 8 22:36:47 2007
New Revision: 122724
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122724
Log:
PR tree-optimization/31085
* tree-ssa-address
--- Comment #1 from cvs-commit at developer dot classpath dot org
2007-03-08 22:14 ---
Subject: Bug 31093
CVSROOT:/cvsroot/classpath
Module name:classpath
Changes by: Tom Tromey 07/03/08 22:13:32
Modified files:
. : ChangeLog
java/net
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-03-08 21:56 ---
With commits #1 to #4, the problem is only partially solved.
As Brooks Moses [1] points out:
"Thus, to make this work right, you'll still need to implement alarm_sub4
and alarm_sub8 library functions (along with al
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-03-08 21:53 ---
Subject: Bug 30947
Author: dfranke
Date: Thu Mar 8 21:53:02 2007
New Revision: 122719
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122719
Log:
2007-03-08 Daniel Franke <[EMAIL PROTECTED]>
Backp
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-03-08 21:50 ---
Subject: Bug 30947
Author: dfranke
Date: Thu Mar 8 21:49:59 2007
New Revision: 122717
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122717
Log:
2007-03-08 Daniel Franke <[EMAIL PROTECTED]>
Backp
--- Comment #5 from fang at csl dot cornell dot edu 2007-03-08 21:49
---
Ouch, this one seems particularly nasty to me... seeings as this isn't a
regression (at least from 2.95), I don't expect this to be fixed for 4.2. Is
there any chance of this getting attention on the (4.3) mainlin
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-03-08 21:46 ---
Subject: Bug 30947
Author: dfranke
Date: Thu Mar 8 21:46:16 2007
New Revision: 122716
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122716
Log:
2007-03-08 Daniel Franke <[EMAIL PROTECTED]>
PR fo
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-03-08 21:45 ---
Subject: Bug 30947
Author: dfranke
Date: Thu Mar 8 21:45:22 2007
New Revision: 122715
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122715
Log:
2007-03-08 Daniel Franke <[EMAIL PROTECTED]>
PR fo
--- Comment #4 from ulf at linuxmail dot org 2007-03-08 21:33 ---
Yes, I guess you're right. Sorry for the noice, I should have checked it more
closely before posting.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31061
--- Comment #23 from mueller at gcc dot gnu dot org 2007-03-08 21:32
---
Great, this patch makes a -fprefetch-loop-arrays bootstrap succeed. I think
LSHIFT_EXPR should be handled similar.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
--- Comment #7 from burnus at gcc dot gnu dot org 2007-03-08 21:07 ---
Fixed in 4.2 (and 4.3), not a wrong-code bug => Won't fix for 4.1.
Close.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from burnus at gcc dot gnu dot org 2007-03-08 21:06 ---
Subject: Bug 30873
Author: burnus
Date: Thu Mar 8 21:06:37 2007
New Revision: 122711
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122711
Log:
2007-03-08 Paul Thomas <[EMAIL PROTECTED]>
Tobias
See the explanation and test jar at
http://wiki.jboss.org/wiki/Wiki.jsp?page=PromiscuousTraffic
There are 2 problems.
$ gij -jar promiscuoustraffic.jar
java.lang.IllegalArgumentException: Invalid ttl: 0
at java.net.MulticastSocket.setTimeToLive(libgcj.so.8rh)
at
org.jboss.test.cluster.te
On the arm platform, it seems that throwing and catching an exception clobbers
variable-size arrays. The following example exposes the bug:
#include
class exception{};
int main(int argc,char *argv[]) {
/*const*/ int size(32);
int test[size];
test[0] = 1234;
try {
th
--- Comment #17 from tkoenig at gcc dot gnu dot org 2007-03-08 20:38
---
Fixed on trunk and 4.2. Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from geoffk at gcc dot gnu dot org 2007-03-08 20:31 ---
This should be fixed now.
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from amacleod at redhat dot com 2007-03-08 20:20 ---
-fno-tree-fre makes the test case compile, which is further indication FRE is
the problem.
--
amacleod at redhat dot com changed:
What|Removed |Added
--
--- Comment #7 from amacleod at redhat dot com 2007-03-08 20:12 ---
Looking at the original testcase, the complaint is that _t_8232 and _t_3 are
both used in the PHI definition of _t_7. (using mainline from march 5th)
ie, _t_7(ab) = PHI <, _t_8232, ... , _t_3, ...>
That definitio
--- Comment #1 from hjl at lucon dot org 2007-03-08 20:04 ---
Created an attachment (id=13173)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13173&action=view)
A testcase
/usr/gcc-next/bin/gfortran -c -O2 -o 301.o test597.f90
/usr/gcc-next/bin/gfortran -o 301 301.o -Wl,-rpath,/usr
Revision 121302 causes 30% performance regression on Core 2 Duo.
--
Summary: Revision 121302 causes 30% performance regression
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-o
--- Comment #4 from geoffk at gcc dot gnu dot org 2007-03-08 19:56 ---
Subject: Bug 31013
Author: geoffk
Date: Thu Mar 8 19:56:37 2007
New Revision: 122709
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122709
Log:
PR 31013
* gccspec.c (lang_specific_driver): Do
gccspec.c assumes that it can detect Objective-C files because they have a .m
extension, but a user can pass '-ObjC' or '-x objective-c' or '-x c' to
override the extension.
--
Summary: gccspec.c doesn't handle -x options
Product: gcc
Version: 4.3.0
S
--- Comment #16 from tkoenig at gcc dot gnu dot org 2007-03-08 19:27
---
Subject: Bug 30981
Author: tkoenig
Date: Thu Mar 8 19:26:55 2007
New Revision: 122708
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122708
Log:
2007-03-08 Thomas Koenig <[EMAIL PROTECTED]>
PR
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-08 19:15 ---
Here is the patch which I am testing:
Index: c-decl.c
===
--- c-decl.c(revision 1532)
+++ c-decl.c(working copy)
@@ -1650,11 +1650,7 @@ merge_de
--- Comment #3 from patchapp at dberlin dot org 2007-03-08 18:50 ---
Subject: Bug number PR30880
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00497.html
--
http://gcc.gnu.org/bugzilla/sh
The symptom is that compilation aborts as follows
gcc-4.1.2/libssp/ssp.c: In function '__guard_setup':
../../../gcc-4.1.2/libssp/ssp.c:70: warning: implicit declaration of function
'open'
../../../gcc-4.1.2/libssp/ssp.c:70: error: 'O_RDONLY' undeclared (first use in
this function)
BACKGROUND
I a
--- Comment #9 from paulthomas2 at wanadoo dot fr 2007-03-08 18:12 ---
Subject: Re: allocatable component and intent(out) yield
ICE in fold_convert
Daniel,
> --- Comment #8 from dfranke at gcc dot gnu dot org 2007-03-08 16:36
> ---
> Paul, could you have a look at PR31086? I
--- Comment #5 from kargl at gcc dot gnu dot org 2007-03-08 17:58 ---
> Other source in the web (e.g.:
> http://04.code-hosting.com/Fortran/1509485-g95---how-to-build-a-DLL )
> point out the -mrtd would be the option to do the trick.
> None of that works.
What g95 does is on absolutel
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-08 17:54 ---
>gfortran --target-help
> ...
> --add-stdcall-aliasExport symbols with and without @nn
> --disable-stdcall-fixupDon't link _sym to [EMAIL PROTECTED]
> --enable-stdcall-fixup
--- Comment #7 from manu at gcc dot gnu dot org 2007-03-08 17:46 ---
(In reply to comment #6)
> > I thought we eventually agreed that it should be a plain internal_error.
>
> Not until right before the release:
> http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01850.html
>
Nevertheless,
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-03-08 17:40 ---
> I thought we eventually agreed that it should be a plain internal_error.
Not until right before the release:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01850.html
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-08 17:37 ---
"3.2.3-34 to gcc-3.2.3-56", well we don't have multiple releases of 3.2.3.
This should be reported to redhat first. Also 3.2.x is no longer being updated
and has not been for a while now.
--
pinskia at gcc dot
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |tree-optimization
Summary|internal compiler error: in |[4.
--- Comment #3 from burnus at gcc dot gnu dot org 2007-03-08 17:06 ---
> gfortran --target-help
> --add-stdcall-aliasExport symbols with and without @nn
> --disable-stdcall-fixupDon't link _sym to [EMAIL PROTECTED]
> --enable-stdcall-fixup Li
Following an applied update, our gcc attempts for all c source files report:
"output filename specified twice error". As best I can tell, the applied update
was to move from 3.2.3-34 to gcc-3.2.3-56, however the reported version
information seems to indicate the update was not entirely successful.
--- Comment #28 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-08
16:52 ---
Subject: Re: [4.3 regression] ACATS cxh1001 fails
> I don't see what the problem is - you don't have to convert to the base
> type, you can always convert to some standard type of that precision,
> eg
--- Comment #22 from rguenth at gcc dot gnu dot org 2007-03-08 16:38
---
Note that one reason we do not optimize the dead code is the stupidity of VRP
dealing with the IL in the second pass. While in the first pass VRP figures
out a range of [0,5] for w_6 in
:
uexp.1_1 = uexp;
if
--- Comment #8 from dfranke at gcc dot gnu dot org 2007-03-08 16:36 ---
Paul, could you have a look at PR31086? I just filed it before I had a look
here. It may be a dupe, but if so, with a different testcase ...
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-03-08 16:27 ---
I could reduce the testcase slightly. New version:
$> cat ice.f90
MODULE class_dummy_atom_types
TYPE :: dummy_atom_list
TYPE(dummy_atom), DIMENSION(:), POINTER :: table
END TYPE
TYPE :: dummy_atom
TYPE(dummy_at
--- Comment #55 from js at linuxtv dot org 2007-03-08 16:22 ---
Point taken. I was misled by the mentioning of C99 6.3.1.3
in comment #18, that this would apply to integer conversion.
Funnily enough, C99 3.4.3 even says "An example of undefined
behavior is the behavior on integer overfl
The code below causes an ICE with r122699 (20070308). An older version I
happened to have around, gfortran-20070220, crashed as well.
$> cat ice.f90
MODULE class_dummy_atom_types
TYPE :: dummy_atom_list
TYPE(dummy_atom), DIMENSION(:), POINTER :: table
END TYPE
TYPE :: dummy_atom
T
--- Comment #2 from wt at simpack dot de 2007-03-08 16:17 ---
the docs say:
gfortran --target-help
...
--add-stdcall-aliasExport symbols with and without @nn
--disable-stdcall-fixupDon't link _sym to [EMAIL PROTECTED]
--enable-stdcall-fixup
--- Comment #27 from baldrick at free dot fr 2007-03-08 16:06 ---
Subject: Re: [4.3 regression] ACATS cxh1001 fails
> > y = __builtin_nop(x); valid = (y>=lower_bound && y <=upper_bound);
> > The point is that the intrinsic would be opaque to the optimizers,
> > and would only be lowere
--- Comment #6 from manu at gcc dot gnu dot org 2007-03-08 15:52 ---
(In reply to comment #5)
> Subject: Re: -std=c89 doesn't warn about gcc's "?:" extension
>
> On Wed, 7 Mar 2007, manu at gcc dot gnu dot org wrote:
>
> > Sorry, I still don't understand what is the difference between
--- Comment #3 from rakdver at gcc dot gnu dot org 2007-03-08 15:46 ---
Caused by my recent patch.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2007-03-08 15:43 ---
Subject: Re: overflow warnings should not be enabled with -Wall
> I think the description doesn't match the real bug, as explained in comment
> #14
> and #18.
>
> And comment #6 may have a
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-08 15:41 ---
Reducing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-08 15:33 ---
Integer overflow is undefined.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from manu at gcc dot gnu dot org 2007-03-08 15:28 ---
I think the description doesn't match the real bug, as explained in comment #14
and #18.
And comment #6 may have a wink but I think it summarises why the testcase in
comment #3 deserves a warning.
I have my own opin
--- Comment #2 from tbm at cyrius dot com 2007-03-08 15:17 ---
Maybe the same as PR31037
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31080
--- Comment #1 from rolf dot ebert dot gcc at gmx dot de 2007-03-08 15:15
---
This is probably the same problem as mentioned in PR-10768
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10768). See comments #9 - #11.
Bernd Trog developed a workaround available at
http://svn.sourceforge.ne
--- Comment #3 from manu at gcc dot gnu dot org 2007-03-08 14:41 ---
*** Bug 31082 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31083
--- Comment #1 from manu at gcc dot gnu dot org 2007-03-08 14:41 ---
*** This bug has been marked as a duplicate of 31083 ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from sdirkse at gams dot com 2007-03-08 14:39 ---
Created an attachment (id=13172)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13172&action=view)
result of "gcc-save-temps" run on .c file
To reproduce the bug with this file, do:
mamie$gcc -v -DLNX -fPIC -w -m32 -
--- Comment #2 from manu at gcc dot gnu dot org 2007-03-08 14:38 ---
I think you are relying on the fact that signed overflow wraps, when in
standard C it is actually undefined (it may wrap, it may not). To make integers
wrap on overflow you use unsigned or -fwrapv.
Thus, I think this i
My compilation resulted in an internal compiler error and a request to submit a
bug report. Here's the command used and it's output: the input will be
attached.
mamie:$gcc -v -DLNX -fPIC -w -m32 -fwrapv -O3 -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -c utilcomp.i
Using built-in specs.
Target: i68
/test/gnu/gcc/objdir/./gcc/xgcc -shared-libgcc -B/test/gnu/gcc/objdir/./gcc
-nos
tdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src
-L/test/gn
u/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs
-B/opt/gnu/gcc/gcc-4.3
.0/hppa2.0w-hp-hpux11.11/bin/
-B/opt/gnu/gcc/gcc-4.3.0/h
--- Comment #2 from pault at gcc dot gnu dot org 2007-03-08 14:23 ---
Created an attachment (id=13171)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13171&action=view)
A fix for the PR
The attached regtests on Cygwin_NT/PIV.
I will submit it to the list tonight.
Paul
--
paul
--- Comment #1 from niklas at cadence dot com 2007-03-08 14:17 ---
I am running on a 64-bit machine, not 32-bit as stated in the first line. Typo,
sorry.
--
niklas at cadence dot com changed:
What|Removed |Added
The following code hangs for -O2 or -O3. I am running on a 32-bit machine, and
with -O1 it terminates after a few seconds:
for (int i = 1; i != 0; i++);
You can replace 'i = 1' with 'i = (1<<30)' for faster testing.
I am running Gentoo Linux 64-bit. 'gcc --version' says: gcc (GCC) 4.1.1 (Gen
The following code hangs for -O2 or -O3. I am running on a 32-bit machine, and
with -O1 it terminates after a few seconds:
for (int i = 1; i != 0; i++);
You can replace 'i = 1' with 'i = (1<<30)' for faster testing.
I am running Gentoo Linux 64-bit. 'gcc --version' says: gcc (GCC) 4.1.1 (Gen
--- Comment #38 from fxcoudert at gcc dot gnu dot org 2007-03-08 13:33
---
No backport to 4.1, said the maintainer. Closing accordingly.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #37 from burnus at gcc dot gnu dot org 2007-03-08 13:24 ---
Can this be closed or do you intent to backport it to 4.1?
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from gdr at cs dot tamu dot edu 2007-03-08 13:20 ---
Subject: Re: [4.3 Regression] warning: same canonical type node for different
types
"manu at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| --- Comment #3 from manu at gcc dot gnu dot org 2007-03-08 11:40 ---
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-08 13:10 ---
Reduced testcase:
char a[1];
void
error (int journal )
{
const char *b = journal?a: "";
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #26 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-08
12:54 ---
Subject: Re: [4.3 regression] ACATS cxh1001 fails
> y = __builtin_nop(x); valid = (y>=lower_bound && y <=upper_bound);
> The point is that the intrinsic would be opaque to the optimizers,
> and would o
1 - 100 of 128 matches
Mail list logo
