H.J. Lu [EMAIL PROTECTED] wrote on 27.04.2008 21:31:14:
Is this related to
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01951.html
H.J.
On Sun, Apr 27, 2008 at 11:47 AM, FX [EMAIL PROTECTED] wrote:
Cygwin native built gfortran 4.4 was already broken, even when it
was
making it
On 2008/4/28 Ben Elliston [EMAIL PROTECTED] wrote:
On Sun, 2008-04-27 at 21:45 +0200, J.C. Pizarro wrote:
Don't be stupid!
Could you be a bit more civil, please? It's fairly unusual for people
on this list to talk to each other in this way.
Thanks,
Ben
Excuse me, i'm not the
Hi,
I've been rebootstrapping my switch conversion patch (which is still
waiting for review) to make sure it still works. Unfortunately, it
did not. The error given was the following and I believe this is the
warning introduced by Ian as a response to the infamous CERT advisory.
Hello,
I am looking at a testsuite failure (wo_prof_global_var.c) in my
porting. Somehow, I found GCC 4.3.0 seems to generate unnecessary malloc
during structure optimization. In the code, the structure is split into
two individual fields (D.2240 and D.2242) and they are allocated
separately. But
I am trying to look at assembler code, and representing it as C code.
For ia32, x86 platforms,
assembler like the following
ADD eax,ebx;
JO integer_overflow_detected;
How would I represent this in C?
Kind Regards
James
[EMAIL PROTECTED] wrote on 28.04.2008 13:11:39:
I am trying to look at assembler code, and representing it as C code.
For ia32, x86 platforms,
assembler like the following
ADD eax,ebx;
JO integer_overflow_detected;
How would I represent this in C?
Kind Regards
James
It would be
Dear Reader,
A few years ago I had already posted a question about implementing a
metrication tool in GCC, i.e. a tool that can measure several metrics
from the source code. Examples could be, the number of variables,
number of multiplications, number of loops, number of functions, etc.
At that
On Mon, Apr 28, 2008 at 09:07:51AM +0200, J.C. Pizarro wrote:
Excuse me, i'm not the unique and first person that says you stupid,
GCC did it too.
GCC is not posting on the mailing list. Please be polite to other
contributors; that includes not insulting their intelligence.
--
Daniel
2008/4/28 Kai Tietz [EMAIL PROTECTED]:
[EMAIL PROTECTED] wrote on 28.04.2008 13:11:39:
I am trying to look at assembler code, and representing it as C code.
For ia32, x86 platforms,
assembler like the following
ADD eax,ebx;
JO integer_overflow_detected;
How would I
James Courtier-Dutton [EMAIL PROTECTED] wrote on 28.04.2008
15:28:56:
2008/4/28 Kai Tietz [EMAIL PROTECTED]:
[EMAIL PROTECTED] wrote on 28.04.2008 13:11:39:
I am trying to look at assembler code, and representing it as C
code.
For ia32, x86 platforms,
assembler like the
Mark Mitchell wrote:
Janis Johnson wrote:
This will involve editing every test that using dg-options
to add a -mcpu/-march flag. Would it make sense to let
dg-options check for the conflict as it adds an option?
Yes, it would meaning adding the new option to hundreds of tests,
but
On 4/28/08 7:46 AM, Roel Meeuws wrote:
So here is what I would like to know: what kind of metrics could I
measure at e.g. GIMPLE level, and what steps do I need to take to
implement a pass for GIMPLE to measure the needed values?
You can measure anything that is language-independent (though
J.C. Pizarro wrote on :
On 2008/4/28 Ben Elliston wrote:
On Sun, 2008-04-27 at 21:45 +0200, J.C. Pizarro wrote:
Don't be stupid!
Could you be a bit more civil, please? It's fairly unusual for people
on this list to talk to each other in this way.
Thanks,
Ben
Excuse me, i'm
On 2008/4/28 Dave Korn [EMAIL PROTECTED] wrote:
J.C. Pizarro wrote on :
On 2008/4/28 Ben Elliston wrote:
On Sun, 2008-04-27 at 21:45 +0200, J.C. Pizarro wrote:
Don't be stupid!
Could you be a bit more civil, please? It's fairly unusual for people
on this list to talk
Joel Sherrill wrote:
1. Make these tests say something about what capability they require,
with a dg-require directive, and then write autoconf-style tests run by
the testsuite to determine whether the current compiler has that
capability. For example, add a dg-require-hard-float directive,
I've just tested gcc/gfortran with CP2K, which some of you might know from
PR29975 and other messages to the list, and observed some very pleasing
evolution in the runtime of the code. In each case the set of compilation
options is '-O2 -ffast-math -funroll-loops -ftree-vectorize
On 2008/4/27 J.C. Pizarro [EMAIL PROTECTED] wrote:
On Fri 25 Apr 2008 22:22:55 -0500, Peter Bergner [EMAIL PROTECTED] wrote:
The difference between a compressed upper triangular bit matrix from a
standard
upper triangular bit matrix like the one above, is we eliminate space from
the
On Mon, 2008-04-28 at 07:47 -0700, Mark Mitchell wrote:
Joel Sherrill wrote:
1. Make these tests say something about what capability they require,
with a dg-require directive, and then write autoconf-style tests run by
the testsuite to determine whether the current compiler has that
[ Apologies if this comes out twice. I posted this message last week,
but I think it was rejected because of a .pdf attachment. ]
We have been bouncing ideas for a new mechanism to describe the behavior
of function calls so that optimizers can be more aggressive at call
sites. Currently,
On Mon, Apr 28, 2008 at 3:04 PM, Diego Novillo [EMAIL PROTECTED] wrote:
[ Apologies if this comes out twice. I posted this message last week,
but I think it was rejected because of a .pdf attachment. ]
We have been bouncing ideas for a new mechanism to describe the behavior
of function
Hi,
I noticed that x86 builtin load functions aren't defined
with def_builtin_const. Is this an oversight or intentional?
Thanks.
H.J.
On Mon, Apr 28, 2008 at 12:47 PM, H.J. Lu [EMAIL PROTECTED] wrote:
I noticed that x86 builtin load functions aren't defined
with def_builtin_const. Is this an oversight or intentional?
I don't see why they can't be defined as const, the only time I can
think of is when you have
Diego Novillo wrote:
[ Apologies if this comes out twice. I posted this message last week,
but I think it was rejected because of a .pdf attachment. ]
We have been bouncing ideas for a new mechanism to describe the behavior
of function calls so that optimizers can be more aggressive at call
Peter Bergner wrote:
On Thu, 2008-04-24 at 20:23 -0400, Vladimir Makarov wrote:
Hi, Peter. The last time I looked at the conflict builder
(ra-conflict.c), I did not see the compressed matrix. Is it in the
trunk? What should I look at?
Yes, the compressed bit matrix was committed
I am combining most x86 SIMD builtins into bdesc_sse_args.
I only define store builtins with def_builtin. The rest will be
defined with def_builtin_const., including load builtins. I want
to make sure that it is OK to do so.
Thanks.
H.J.
On Mon, Apr 28, 2008 at 12:50 PM, Andrew Pinski [EMAIL
On Mon, 2008-04-28 at 16:01 -0400, Vladimir Makarov wrote:
Thanks, Peter. That was clever and email is very enlightening. I have
analogous idea for more compact conflict matrix representation. IRA
builds allocno live ranges first (they are ranges of program points
where the allocno
On Apr 28, 2008, at 12:04 PM, Diego Novillo wrote:
[ Apologies if this comes out twice. I posted this message last week,
but I think it was rejected because of a .pdf attachment. ]
We have been bouncing ideas for a new mechanism to describe the
behavior
of function calls so that
Hi guys,
I am trying to get as close mapping from liveness information ( in
bb-il.rtl-global_live_at_start )
to global and local variables as possible. Mapping to stack slots
would be a good first step.
What data structures should I look at use?
What would be the best way to do it?
Any
Peter Bergner wrote:
On Mon, 2008-04-28 at 16:01 -0400, Vladimir Makarov wrote:
Thanks, Peter. That was clever and email is very enlightening. I have
analogous idea for more compact conflict matrix representation. IRA
builds allocno live ranges first (they are ranges of program points
Snapshot gcc-4.1-20080428 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080428/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Load builtins can't be const since they may return different values on
the same pointer value.
H.J.
On Mon, Apr 28, 2008 at 1:19 PM, H.J. Lu [EMAIL PROTECTED] wrote:
I am combining most x86 SIMD builtins into bdesc_sse_args.
I only define store builtins with def_builtin. The rest will be
On Mon, Apr 28, 2008 at 5:16 PM, H.J. Lu [EMAIL PROTECTED] wrote:
Load builtins can't be const since they may return different values on
the same pointer value.
They should be pure though.
-- Pinski
Martin Jambor [EMAIL PROTECTED] writes:
I've been rebootstrapping my switch conversion patch (which is still
waiting for review) to make sure it still works. Unfortunately, it
did not. The error given was the following and I believe this is the
warning introduced by Ian as a response
On Mon, 2008-04-28 at 18:07 -0400, Vladimir Makarov wrote:
I am currently working on bit matrix compression. It is not implemented
yet. I hope it will be ready in a week.
Ahh, ok. Well, hopefully the code I wrote on the trunk is useful for IRA.
If you have questions about it, let me know,
-- Forwarded message --
From: NoFirst NoLast [EMAIL PROTECTED]
Date: Mon, Apr 28, 2008 at 6:46 PM
Subject: gcc cross compiler problem
To: gcc@gcc.gnu.org
Hello gcc,
I am running into a problem when I am trying to compile GCC to run on
a i686-pc-linux-gnu (host) but to build
Diego Novillo wrote:
We have been bouncing ideas for a new mechanism to describe the behavior
of function calls so that optimizers can be more aggressive at call
sites. Currently, GCC supports the notion of pure/impure,
const/non-const, but that is not enough for various cases.
Fortran
--- Comment #2 from ubizjak at gmail dot com 2008-04-28 07:38 ---
No, we need -msse for i686 here since vector floats have to go into xmm
register.
I will fix this.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #3 from uros at gcc dot gnu dot org 2008-04-28 07:42 ---
Subject: Bug 36056
Author: uros
Date: Mon Apr 28 07:42:12 2008
New Revision: 134743
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134743
Log:
PR testsuite/36056
* g++.dg/ext/vector14.C: Add
--- Comment #3 from uros at gcc dot gnu dot org 2008-04-28 07:52 ---
Subject: Bug 36064
Author: uros
Date: Mon Apr 28 07:52:01 2008
New Revision: 134744
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134744
Log:
PR target/36064
* config/i386/i386.md
--- Comment #4 from ubizjak at gmail dot com 2008-04-28 08:00 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL|
--- Comment #4 from ubizjak at gmail dot com 2008-04-28 08:01 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL|
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-04-28 09:09 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-28 09:22 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-04-28 09:23 ---
Subject: Bug 34223
Author: rguenth
Date: Mon Apr 28 09:22:28 2008
New Revision: 134747
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134747
Log:
2008-04-28 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-04-28 09:10 ---
Subject: Bug 36066
Author: rguenth
Date: Mon Apr 28 09:09:19 2008
New Revision: 134745
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134745
Log:
2008-04-28 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #6 from jakub at gcc dot gnu dot org 2008-04-28 09:51 ---
Subject: Bug 36060
Author: jakub
Date: Mon Apr 28 09:50:31 2008
New Revision: 134751
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134751
Log:
PR debug/36060
* dwarf2out.c (struct die_struct):
--- Comment #5 from jakub at gcc dot gnu dot org 2008-04-28 09:46 ---
Subject: Bug 36060
Author: jakub
Date: Mon Apr 28 09:45:26 2008
New Revision: 134750
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134750
Log:
PR debug/36060
* dwarf2out.c (struct die_struct):
--- Comment #7 from jakub at gcc dot gnu dot org 2008-04-28 09:52 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-04-28 09:39 ---
For testvectdp2 we now miss to apply store-motion so the reduction is no longer
recognized. This is the bad interaction between PRE and lim for which we have
PR36009. If you add -fno-tree-pre vectorization fails
When compiling the following file with g++ 4.3.0, with -Wall :
main.cpp
struct foo {
bool a;
volatile bool b,c; // removing 'volatile' here removes the warning.
foo() { a = b = c = false; }
};
int main() {
foo A;
}
-- end of main.cpp --
-bash-3.00$ g++ main.cpp -Wall
--- Comment #1 from David dot Tschumperle at greyc dot ensicaen dot fr
2008-04-28 10:55 ---
Also, removing the warning without adding or removing 'volatile' can be
achieved by writting :
foo() { a = (b = (c = false)); }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36069
--- Comment #16 from bero at arklinux dot org 2008-04-28 10:59 ---
ping...
This missed 4.3 again, it should probably get in now before 4.4 enters freeze
mode...
Re the moc - moc-qt4 change suggested in comment #14: This should be detected
by the configure script, moc-qt4 is a
In gcc/config/m68k/linux-unwind.h, the function m68k_fallback_frame_state() has
the following:
if (*(int *) sc-sc_fpstate)
{
int *fpregs = (int *) sc-sc_fpregs;
fs-regs.reg[16].how = REG_SAVED_OFFSET;
fs-regs.reg[16].loc.offset = (long) fpregs[0] - cfa;
fs-regs.reg[17].how =
--- Comment #2 from pault at gcc dot gnu dot org 2008-04-28 11:55 ---
Created an attachment (id=15541)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15541action=view)
Fix for this PR
This seems to do the job. The problem arises because the present version of
module.c does not add
--- Comment #1 from jakub at gcc dot gnu dot org 2008-04-28 11:56 ---
Can you reproduce it with a newer snapshot? Can you find out which change
between 0219 and 0227 caused it? There were very few changes that might affect
it at all, I'd say just PR35071, PR35265, PR34971 and PR35390,
--- Comment #5 from uros at gcc dot gnu dot org 2008-04-28 12:18 ---
Subject: Bug 36056
Author: uros
Date: Mon Apr 28 12:17:27 2008
New Revision: 134752
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134752
Log:
PR testsuite/36056
* g++.dg/ext/vector14.C: Add
--- Comment #2 from riku dot voipio at iki dot fi 2008-04-28 12:26 ---
Newer arm builds of gcc-4.3 in debian have succeeded fine, so I'd say this bug
can be closed. One theory could be that this build machine simply ran out of
Memory during the build (although a later build on similar
--- Comment #5 from burnus at gcc dot gnu dot org 2008-04-28 12:34 ---
Further reports: They might show the same problem, or also different ones. I
did not check them all:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/c553e0034bab977c
* * *
Patch by FX:
2 days old trunk fails on CVS CP2K [see PR29975] with
gfortran -c -v -O2 -ffast-math -funroll-loops -ftree-vectorize -march=native
-ffree-form -D__GFORTRAN -D__FFTSG
-D__COMPILE_ARCH=\Linux-x86-64-gfortran\ -D__COMPILE_DATE=\Mon Apr 28
14:33:23 CEST 2008\ -D__COMPILE_HOST=\pcihopt3\
--- Comment #149 from jv244 at cam dot ac dot uk 2008-04-28 12:45 ---
new ICE, PR36071.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #1 from jv244 at cam dot ac dot uk 2008-04-28 12:48 ---
trace
rogram received signal SIGSEGV, Segmentation fault.
0x005b4e18 in operand_equal_p (arg0=0x2b9220d76420,
arg1=0x2b9220c5b240, flags=0) at
/data03/vondele/gcc_trunk/gcc/gcc/fold-const.c:3037
3037 if
--- Comment #2 from jv244 at cam dot ac dot uk 2008-04-28 12:55 ---
revision 134754 seems to pass.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36071
--- Comment #3 from jakub at gcc dot gnu dot org 2008-04-28 13:32 ---
Closing then, if you manage to reproduce it again, please reopen with more
details.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jv244 at cam dot ac dot uk 2008-04-28 13:56 ---
assuming fixed
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
When linking a program build with gfortran 4.3.0 to lapack, I get
/opt/atlas-gnu_4.3.0/3.8.1/lib64/liblapack.so: undefined reference to
`_gfortran_pow_r8_i4'
/opt/atlas-gnu_4.3.0/3.8.1/lib64/liblapack.so: undefined reference to
`_gfortran_pow_r4_i4'
--
Summary: missing symbols in
--- Comment #1 from sliwa at cft dot edu dot pl 2008-04-28 14:47 ---
See
http://forums.amd.com/devforum/messageview.cfm?catid=217threadid=90399messid=881726parentid=856116FTVAR_FORUMVIEWTMP=Branch
for a similar complaint.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36072
--- Comment #2 from sliwa at cft dot edu dot pl 2008-04-28 15:02 ---
OK, the LAPACK library was probably compiled with 4.1.2.
--
sliwa at cft dot edu dot pl changed:
What|Removed |Added
This is my first ever bug report; if I get something wrong, please tell me so I
don't do it again!
When the following is compiled using mainline (as of 28th April 2008) with -O
-march=nocona -mfpmath=sse,387 -ffast-math I get an ICE. It's a different ICE
with omitting the -O2.
-
Code:
-
model: posix
gcc version 4.4.0 20080428 (experimental) [trunk revision 134754] (GCC)
--
ejb48 at cam dot ac dot uk changed:
What|Removed |Added
Known to fail
--- Comment #2 from jaydub66 at gmail dot com 2008-04-28 15:44 ---
(In reply to comment #1)
I think compiling with -fbacktrace and calling the STOP intrinsic should emit
a
backtrace.
I don't think it does. Anyway I'm looking for a solution that keeps the program
running after the
-ffast-math -o x.s
Starting program:
/usr/gcc-4.4/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/cc1plus -fpreprocessed
x.ii -quiet -dumpbase x.ii -mtune=generic -auxbase x -O2 -version -ffast-math
-o x.s
GNU C++ (GCC) version 4.4.0 20080428 (experimental) [trunk revision 134755]
(x86_64-unknown-linux-gnu
--- Comment #2 from ubizjak at gmail dot com 2008-04-28 16:20 ---
Mine.
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Comment #3 from burnus at gcc dot gnu dot org 2008-04-28 16:41 ---
I think compiling with -fbacktrace and calling the STOP intrinsic should
emit a backtrace.
I think it should not. For abort(), I think a backtrace is ok, but for STOP
there should be no backtrace. Using stop is
--- Comment #1 from hjl dot tools at gmail dot com 2008-04-28 17:22 ---
Revision 134730 is the cause.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Known to fail||4.4.0
Known to work||4.3.0
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #3 from uros at gcc dot gnu dot org 2008-04-28 17:50 ---
Subject: Bug 36073
Author: uros
Date: Mon Apr 28 17:49:51 2008
New Revision: 134757
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134757
Log:
PR target/36073
* config/i386/i386.md
--- Comment #4 from ubizjak at gmail dot com 2008-04-28 17:54 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL|
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-04-28 18:31 ---
I bet this is fixed with revision 134745.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36074
--- Comment #3 from hjl dot tools at gmail dot com 2008-04-28 18:37 ---
(In reply to comment #2)
I bet this is fixed with revision 134745.
In my initial bug report, I said Gcc 4.4 revision 134755 failed to compile
^^^
447.dealII
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-04-28 19:19 ---
A preprocessed testcase is always appreciated ;) But yes, I have access to
spec 2006.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36074
--- Comment #7 from sjhowe at dial dot pipex dot com 2008-04-28 20:17
---
Roger
I agree with your analysis. I am slightly crestfallen as I was suspicious that
Barriato, Hofri etc's paper never mentioned worst case only approximate
case. And I have now seen BFPRT73 paper where it
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-04-28 20:19 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-04-28 20:28 ---
The testcase from comment #1 is fixed on the trunk. The original testcase
still
shows (int)a 1 != 0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14792
--- Comment #36 from jason at gcc dot gnu dot org 2008-04-28 20:44 ---
Subject: Bug 57
Author: jason
Date: Mon Apr 28 20:43:27 2008
New Revision: 134762
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134762
Log:
PR c++/57
* parser.c
--- Comment #9 from pault at gcc dot gnu dot org 2008-04-28 21:03 ---
This is not critical in the gcc sense - I would change it back to normal if I
were you. After all, this feature of F95 has never worked correctly:)
Cheers
Paul
--
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2008-04-28 21:16
---
Subject: Bug 36007
Author: ebotcazou
Date: Mon Apr 28 21:15:41 2008
New Revision: 134766
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134766
Log:
PR ada/36007
* decl.c
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-04-28 21:18
---
This should be OK now.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from tkoenig at gcc dot gnu dot org 2008-04-28 21:34
---
Created an attachment (id=15542)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15542action=view)
proposed patch
This fixes the test case.
Regression-test and submission probably tomorrow.
--
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-04-28 21:36 ---
Confirmed, this would indeed be useful.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ianw at vmware dot com 2008-04-28 22:14 ---
As another data-point,
if ( (a=10) ) ;
also doesn't warn. I'm not sure what the standard says on that, but other
contemporary compilers do give the an assignment used as truth value warning
for the example above.
--
--- Comment #4 from ianw at vmware dot com 2008-04-28 22:16 ---
Oh, just to be clear, my point was if (a=10) warns, but the extra parenthesis
hide the warning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25733
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-04-28 22:17 ---
(In reply to comment #4)
Oh, just to be clear, my point was if (a=10) warns, but the extra parenthesis
hide the warning.
That is by design.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25733
--- Comment #6 from ianw at vmware dot com 2008-04-28 22:28 ---
(In reply to comment #5)
(In reply to comment #4)
Oh, just to be clear, my point was if (a=10) warns, but the extra
parenthesis
hide the warning.
That is by design.
Ok, I did try looking but is that documented
--- Comment #7 from rwild at gcc dot gnu dot org 2008-04-28 22:28 ---
Subject: Bug 35169
Author: rwild
Date: Mon Apr 28 22:27:22 2008
New Revision: 134768
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134768
Log:
gcc/
PR bootstrap/35169
* optc-gen.awk: Work
--- Comment #6 from manus at eiffel dot com 2008-04-28 22:34 ---
I can reproduce this problem with gcc 4.2.3 that comes with Ubuntu 8.04 on
PowerPC with the following command line:
gcc -Wall -mlongcall -fPIC -c foo.c
Removing either `-fPIC' or `-mlongcall' succeeds, it is when used
Executing on host: /mnt/gnu/gcc/objdir/gcc/xgcc -B/mnt/gnu/gcc/objdir/gcc/
/mnt/
gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/20021119-1.c -w -O2
-fno-show
-column -lm -o /mnt/gnu/gcc/objdir/gcc/testsuite/gcc/20021119-1.x2
(timeou
t = 300)
PASS: gcc.c-torture/execute/20021119-1.c
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2008-04-29 03:14
---
The patch fixes sum, product, and minloc. Regression tests OK on x86-64.
Thanks for patch.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from intvnut at gmail dot com 2008-04-29 03:42 ---
(In reply to comment #5)
It should be possible to have an alternate implementation in libgcc2.c by
means
of just selecting on a proper architecture define or the size of the argument
mode.
I see where it would go
--- Comment #9 from bkoz at gcc dot gnu dot org 2008-04-29 04:41 ---
Subject: Bug 35887
Author: bkoz
Date: Tue Apr 29 04:40:08 2008
New Revision: 134776
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134776
Log:
2008-04-28 Benjamin Kosnik [EMAIL PROTECTED]
PR
1 - 100 of 102 matches
Mail list logo
