--- Comment #8 from reichelt at gcc dot gnu dot org 2009-02-19 07:24
---
Fixed-point constants are rejected by the C++ frontend since the patch for
PR39059. So lets turn the PR into the original state: a diagnostic issue
which has been fixed since GCC 4.3.1.
--
reichelt at gcc dot g
--- Comment #4 from reichelt at gcc dot gnu dot org 2009-02-19 07:16
---
Fixed-point constants are rejected by the C++ frontend since the patch for
PR39059.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from reichelt at gcc dot gnu dot org 2009-02-19 07:14
---
The target was i686-pc-linux-gnu.
Yup, this is fixed indeed by the patch for PR39059.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35448
--- Comment #4 from burnus at gcc dot gnu dot org 2009-02-19 07:08 ---
> (ii) Once we have array descriptors that flag the status of the data, include
> pointers in the club?
I prefer to have simple pointers for scalars and use the descriptor only for
arrays/strings/dimension(..) for pe
--- Comment #4 from reichelt at gcc dot gnu dot org 2009-02-19 07:07
---
Btw, fixed-point constants are rejected by the C++ frontend since the patch for
PR39059.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35325
--- Comment #9 from reichelt at gcc dot gnu dot org 2009-02-19 07:03
---
Fixed-point constants are rejected by the C++ frontend since the patch for
PR39059.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #15 from pault at gcc dot gnu dot org 2009-02-19 06:44 ---
Fixed on trunk and 4.3
Thanks for the report
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from pault at gcc dot gnu dot org 2009-02-19 06:43 ---
Subject: Bug 38852
Author: pault
Date: Thu Feb 19 06:43:15 2009
New Revision: 144286
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144286
Log:
2009-02-19 Paul Thomas
PR fortran/38852
PR f
--- Comment #3 from pault at gcc dot gnu dot org 2009-02-19 06:43 ---
Subject: Bug 39006
Author: pault
Date: Thu Feb 19 06:43:15 2009
New Revision: 144286
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144286
Log:
2009-02-19 Paul Thomas
PR fortran/38852
PR fo
uded-gettext --enable-stage1-checking
--enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8
--with-gnu-as --with-as=/usr/local/bin/as --without-gnu-ld
--with-ld=/usr/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local
--without-ppl
Thread model: posix
gcc version 4.4.0 20090218 (exper
--- Comment #4 from pault at gcc dot gnu dot org 2009-02-19 06:04 ---
Tobias,
It seems to me that your proposal to permit this with a warning is good.
However, will it work on all architectures?
I am confirming it with some trepidation since it is not a bug:-)
Paul
--
pault at gc
--- Comment #2 from pault at gcc dot gnu dot org 2009-02-19 05:56 ---
Confirmed
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCO
--- Comment #3 from pault at gcc dot gnu dot org 2009-02-19 05:52 ---
I wonder if this should not be fixed ultimately by:
(i) Allowing allocatable scalars, which should allow rank 0 descriptors to take
the field; and
(ii) Once we have array descriptors that flag the status of the data, i
--- Comment #3 from pault at gcc dot gnu dot org 2009-02-19 05:44 ---
Thomas, As a matter of curiosity, do other compilers catch this?
Confirmed
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pault at gcc dot gnu dot org 2009-02-19 05:40 ---
I agree with Steve and have marked this as WONTFIX.
You should use another pointer and allocate to that if you want to avoid the
automatic deallocation on leaving scope.
Paul
--
pault at gcc dot gnu dot org chang
in/as --with-gnu-ld
--with-ld=/usr/local/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local
--without-ppl
Thread model: posix
gcc version 4.4.0 20090218 (experimental) [trunk revision 144279] (GCC)
# gmake
(hours)
...
mkdir META-INF
mkdir META-INF/services
./copy-vmresources.sh[34]: mkinstalldirs
-double-128 --with-included-gettext --enable-stage1-checking
--enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8
--with-gnu-as --with-as=/usr/local/bin/as --without-gnu-ld
--with-ld=/usr/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local
--without-ppl
Thread model: posix
gcc version 4
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-02-19
02:32 ---
Fixed on current gcc trunk.
--
howarth at nitro dot med dot uc dot edu changed:
What|Removed |Added
--
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-02-19
02:31 ---
Fixed on current gcc trunk.
--
howarth at nitro dot med dot uc dot edu changed:
What|Removed |Added
--
--- Comment #2 from rob1weld at aol dot com 2009-02-19 02:30 ---
That worked.
The build continues until it fails here:
# gmake
(5 minutes)
...
Making all in src
gmake[4]: Entering directory
`/usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/src'
...
-DPIC -o .libs/parallel_set
--- Comment #1 from rob1weld at aol dot com 2009-02-19 02:21 ---
New warning "different GCC executable" was just 'xgcc' instead of 'g++'.
Next error in 'extc++.h.gch/O2g.gch' is fixed by:
/usr/share/src/gcc_build/./gcc/xgcc -shared-libgcc
-B/usr/share/src/gcc_build/./gcc -nostdinc++
-
nu-ld
--with-ld=/usr/local/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local
--without-ppl
Thread model: posix
gcc version 4.4.0 20090218 (experimental) [trunk revision 144279] (GCC)
# gmake
...
Making all in include
gmake[4]: Entering directory
`/usr/share/src/gcc_build/i386-pc-solaris2.11/
--- Comment #8 from hjl at gcc dot gnu dot org 2009-02-19 01:58 ---
Subject: Bug 39219
Author: hjl
Date: Thu Feb 19 01:58:15 2009
New Revision: 144284
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144284
Log:
gcc/cp
2009-02-18 H.J. Lu
PR c++/39219
* parser.
--- Comment #27 from jason at gcc dot gnu dot org 2009-02-19 01:12 ---
I reverted the mistaken checkins a few seconds later.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
--- Comment #3 from hjl dot tools at gmail dot com 2009-02-18 23:45 ---
(In reply to comment #2)
> A patch is posted at
>
> http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00714.html
>
Jason, Richard, can you review this wrong-code fix? Thanks.
--
hjl dot tools at gmail dot com chang
--- Comment #7 from hjl dot tools at gmail dot com 2009-02-18 23:44 ---
(In reply to comment #3)
> A patch is posted at
>
> http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00790.html
>
Jason, can you take a look at this one line fix? Thanks.
--
hjl dot tools at gmail dot com changed:
--- Comment #14 from hjl dot tools at gmail dot com 2009-02-18 23:42
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #4 from janis at gcc dot gnu dot org 2009-02-18 23:18 ---
Subject: Bug 38165
Author: janis
Date: Wed Feb 18 23:17:56 2009
New Revision: 144277
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144277
Log:
2009-02-18 Jack Howarth
PR testsuite/38165
* g
--- Comment #2 from janis at gcc dot gnu dot org 2009-02-18 22:19 ---
Subject: Bug 38166
Author: janis
Date: Wed Feb 18 22:19:26 2009
New Revision: 144274
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144274
Log:
2009-02-18 Jack Howarth
PR testsuite/38166
* g
--- Comment #2 from dpirch at gmail dot com 2009-02-18 22:16 ---
extfunc cannot change the value of f, it would lead to undefined behavior.
"If an attempt is made to modify an object defined with a const-qualified type
through use of an lvalue with non-const-qualified type, the behavior
--- Comment #5 from caroline dot rioux at ca dot ibm dot com 2009-02-18
22:15 ---
(In reply to comment #4)
> Nope, only currently 4.2 and above are being maintained. Is there a reason
> why
> you unlikely to move to 4.x in the short term?
We have a big code base and changing compile
--- Comment #26 from ebotcazou at gcc dot gnu dot org 2009-02-18 22:11
---
> Fixed. The C++ static/extern issue has been added as PR 39236.
You have installed a lot more things than what's described in the ChangeLog.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-02-18 22:06 ---
(In reply to comment #3)
> Ok thanks for your input. Was this explicitly fixed or a result of other
> framework changes? Is there any way a patch exists and could be applied?
Off hand I don't know.
> I ask because
--- Comment #3 from caroline dot rioux at ca dot ibm dot com 2009-02-18
22:02 ---
(In reply to comment #2)
> Fixed in 4.1.0 as mentioned already. 3.3.x is no longer maintained and any
> bug
> that is reported against that old version is most likely not going to be ever
> fixed.
>
Ok
On Mon, Feb 16, 2009 at 7:29 PM, e211 wrote:
>
> //The following code works and there is no way it should. Seems like a bug
> someone put in on purpose
>
> #include
> using namespace std;
>
> void swap(int *x, int *y)
> {
>int temp;
>temp = *x;
>*x = *y;
>*y = tem
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-18 21:55 ---
We need a preprocessed source or at least a self contained example. It might
be the case you don't use the correct barriers or atomics when doing updates of
a global variable.
--
pinskia at gcc dot gnu dot org c
--- Comment #17 from danglin at gcc dot gnu dot org 2009-02-18 21:54
---
Configuring with --disable-stage-checking, I see the following for cc1:
-bash-3.2$ size cc1
text data bss dechex filename
28977798 496932 623152 300978821cb41da
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-18 21:45 ---
Fixed in 4.1.0 as mentioned already. 3.3.x is no longer maintained and any bug
that is reported against that old version is most likely not going to be ever
fixed.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #13 from hjl at gcc dot gnu dot org 2009-02-18 21:40 ---
Subject: Bug 39224
Author: hjl
Date: Wed Feb 18 21:40:08 2009
New Revision: 144272
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144272
Log:
2009-02-18 H.J. Lu
PR target/39224
* config/i386
--- Comment #1 from caroline dot rioux at ca dot ibm dot com 2009-02-18
21:39 ---
Created an attachment (id=17327)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17327&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39237
Hello,
We use a unit testing framework which overloads operator new and operator
delete to track memory allocations and detect leaks. According to it, vector's
push_back method allocates memory through operator new but does not release it
through operator delete.
I am not sure if this is because
--- Comment #25 from hjl dot tools at gmail dot com 2009-02-18 21:31
---
All 32bit load insns are zero extended to 64bit, not just move.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17387
--- Comment #24 from hjl dot tools at gmail dot com 2009-02-18 21:24
---
I tried:
--- config/i386/i386.h.zero 2009-02-18 08:42:40.0 -0800
+++ config/i386/i386.h 2009-02-18 13:16:26.0 -0800
@@ -1940,6 +1940,11 @@ do {
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #25 from jason at gcc dot gnu dot org 2009-02-18 21:09 ---
Fixed. The C++ static/extern issue has been added as PR 39236.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
G++ uses TREE_STATIC to mean "will be written out statically somewhere" rather
than "write out statically in this TU"; it should be set on VAR_DECLs that also
have DECL_EXTERNAL set.
Historically we've set DECL_EXTERNAL on anything that we weren't yet sure
whether or not we were going to write out
--- Comment #24 from jason at gcc dot gnu dot org 2009-02-18 21:01 ---
Subject: Bug 39179
Author: jason
Date: Wed Feb 18 21:01:03 2009
New Revision: 144270
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144270
Log:
PR target/39179
* tree-ssa-ccp.c (get_symbol_con
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-18 20:57 ---
Such patch would be obvious and a minor change.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39235
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.3.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39225
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Known to fail|4.3.4 |4.3.4 4.4.0
Known to work|4.4.0 4.3.2 |4.3.2
--- Comment #7 from hjl dot tools at gmail dot com 2009-02-18 20:19 ---
It is caused by revision 143502 on trunk:
http://gcc.gnu.org/ml/gcc-cvs/2009-01/msg00515.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
get_simple_loop_desc uses the XNEW macro to allocate the new loop description,
thus the memory is not initialized.
At least the desc->infinite field thus can remain uninitialized when the
function returns.
As long as the optimizers only punt on infinity that can result in
pseudo-random
missed opti
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-02-18 19:56 ---
I'm sure it is somehow possible, maybe we can use scev_probably_wraps_p
in simple_iv. I will check that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39233
--- Comment #12 from hjl dot tools at gmail dot com 2009-02-18 19:50
---
The updated patch is at
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00871.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-02-18 19:41 ---
(In reply to comment #4)
> You mean anddi3_internal3_nomc, right? If so, I guess anddi3_internal2_nomc
> should be removed too.
I will have to look at what I did, I know I ran into a case where a constant
was being
--- Comment #4 from jakub at gcc dot gnu dot org 2009-02-18 19:40 ---
You mean anddi3_internal3_nomc, right? If so, I guess anddi3_internal2_nomc
should be removed too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39226
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-02-18 19:34 ---
Hmm, for the PS3 toolchain, I think I just removed anddi3_internal3_mc.
Mine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #11 from hjl dot tools at gmail dot com 2009-02-18 19:22
---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00870.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #6 from jakub at gcc dot gnu dot org 2009-02-18 18:56 ---
Would it be possible for known loop bounds to still use pointer etc. ivopts if
we can ensure the overflow doesn't happen on that interval (+-1)? Say if the
same testcase goes for (i = 16; i >= 10; i--) instead of for
--- Comment #10 from hjl dot tools at gmail dot com 2009-02-18 18:53
---
The problem is callee returns long double via a pointer to a structure.
But caller thinks callee returns long double in rax/edx.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39224
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-02-18 18:47 ---
And in the release of 4.3.2 with checking turned on.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-02-18 18:47 ---
This patch fixes it, with unknown side-effects. It should be ok for
the common sizetype extensions due to POINTER_PLUS_EXPR (sizetype is
unsigned for sane languages).
Index: tree-scalar-evolution.c
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-02-18 18:46 ---
And:
GNU C++ (GCC) version 4.4.0 20090116 (experimental) [trunk revision 143448]
(powerpc64-unknown-linux-gnu)
compiled by GNU C version 4.4.0 20090116 (experimental) [trunk revision
143448], GMP version 4.2.
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-02-18 18:46 ---
It works for me with:
GNU C++ (GCC) version 4.4.0 20081229 (experimental) [trunk revision 142951]
(i386-apple-darwin8.11.1)
compiled by GNU C version 4.4.0 20081229 (experimental) [trunk revision
142951], GMP
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-18 18:38 ---
const fptr_t f = inlinable;
extfunc(&f);
f();
extfunc can change the value of f so this is invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from jason at gcc dot gnu dot org 2009-02-18 18:31 ---
...and then of course there's the actual documentation:
TARGET_BINDS_LOCAL_P (tree exp)
Returns true if exp names an object for which name resolution
rules must resolve to the current ``module'' (dynamic shared libra
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #22 from jason at gcc dot gnu dot org 2009-02-18 18:06 ---
Seems like we already had this discussion last year, starting at
http://gcc.gnu.org/ml/gcc/2007-06/msg00848.html
The conclusion there was that binds_local_p means "binds to this
executable/shared library", and the P
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-02-18 17:53 ---
This one also fails on i?86-*-*:
extern void abort (void);
__attribute__((noinline)) void
foo (void *p)
{
long l = (long) p;
if (l < 0 || l > 6)
abort ();
}
int
main ()
{
short i;
for (i = 6; i >= 0; i
rget: x86_64-unknown-linux-gnu
Configured with: ../gcc-svn/configure --program-suffix=-4.4
--enable-languages=c
Thread model: posix
gcc version 4.4.0 20090218 (experimental) (GCC)
--
Summary: Call to constant function pointer not inlined
Product: gcc
Version: 4
--- Comment #21 from jason at gcc dot gnu dot org 2009-02-18 17:51 ---
OTOH, the use of visibility in default_binds_local_p is also wrong under this
interpretation...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-18 17:50 ---
Confirmed on x86_64 with -O2.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
GCC t
--- Comment #20 from jason at gcc dot gnu dot org 2009-02-18 17:47 ---
(In reply to comment #19)
> I suppose it's a question of what "module" means.
"module" is used in a lot of different ways, but this usage definitely refers
to the current translation unit:
/* In a VAR_DECL, FUNCTION
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-18 17:47 ---
I will have a look.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #15 from hjl dot tools at gmail dot com 2009-02-18 17:43
---
(In reply to comment #13)
> Created an attachment (id=17325)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17325&action=view) [edit]
> Ada testcase
>
> (botca...@red) ~ $ gcc -S p.ads
> p.ads:16: note: The A
--- Comment #2 from burnus at gcc dot gnu dot org 2009-02-18 17:32 ---
The other bug is PR 29616.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39230
--- Comment #1 from burnus at gcc dot gnu dot org 2009-02-18 17:28 ---
> This is actually invalid
Yes, but this is a requirement to the program(mer) not to the compiler.
> and should probably trigger a runtime error.
Yes, but only with some checking option, otherwise it really gets too
--- Comment #1 from jakub at gcc dot gnu dot org 2009-02-18 17:24 ---
Caused by PR31358.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39233
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39233
extern void abort (void);
__attribute__((noinline)) void
foo (void *p)
{
long l = (long) p;
if (l < 0 || l > 6)
abort ();
}
int
main ()
{
int i;
for (i = 6; i >= 0; i--)
foo ((void *) (long) i);
return 0;
}
is miscompiled (into endless loop). First ivopts decides to use a poin
--- Comment #6 from sebor at roguewave dot com 2009-02-18 16:50 ---
(In reply to comment #5)
> Should attribute work on enum constants?
Not sure if this is a question for me but IMO, it should. I would expect
individual enumerators to be more heavily referenced than their types
(sometim
--- Comment #1 from regehr at cs dot utah dot edu 2009-02-18 16:41 ---
Created an attachment (id=17326)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17326&action=view)
failure-inducing C program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39232
--- Comment #2 from burnus at gcc dot gnu dot org 2009-02-18 16:41 ---
> I'm not sure if this kind of thing is legal to begin with
Well, the Fortran standard only has:
Free form: "If a line consists entirely of characters of default kind (4.4.4),
it may contain at most 132 characters.
This is seen on the version of avr-gcc 4.3.3 that gets built by the script that
comes with FemtoOS 0.88.
I'm compiling like this:
avr-gcc -mmcu=atmega128 -O0 small_preprocessed.c -o small.elf
And observing the result of a run like this:
java -server avrora.Main -platform=mica2 -simulation=s
--- Comment #9 from hjl dot tools at gmail dot com 2009-02-18 15:50 ---
For sysv/x86-64, XFmode is 16byte with 16byte alignment. It is
passed in memory and returned in in %st0/%st1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39224
--- Comment #4 from eric dot weddington at atmel dot com 2009-02-18 15:19
---
Fail on 4.3.2 with -O1, success with -O[023s].
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
-
--- Comment #14 from hjl dot tools at gmail dot com 2009-02-18 15:10
---
(In reply to comment #12)
> > I believe that warning is turned on for C ObjC C++ ObjC++ only.
>
> Wrong.
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00834.html
--
http://gcc.gnu.org/bu
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-02-18
14:56 ---
Submitted patch to gcc-patches...
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00831.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38165
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2009-02-18 14:51
---
Created an attachment (id=17325)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17325&action=view)
Ada testcase
(botca...@red) ~ $ gcc -S p.ads
p.ads:16: note: The ABI of passing union with long double has
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2009-02-18 14:38
---
> I believe that warning is turned on for C ObjC C++ ObjC++ only.
Wrong.
spgn_numerics.ads: In function 'Test_Gip_Stat':
spgn_numerics.ads:25: note: The ABI of passing union with long double has
changed in GCC
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-18 14:37 ---
gcc -o t t.c -O2 -Wstrict-overflow
t.c: In function main:
t.c:13: warning: assuming signed overflow does not occur when simplifying
conditional to constant
negating signed 0x8000 invokes undefined behavior.
The following code gives wrong result with -O2 and above :
% gcc -O0 -o example example.c && ./example
1
% gcc -O2 -o example example.c && ./example
0
The bug is triggered on i486 platform, with gcc 4.3.2 but not with gcc 4.1.2.
#include
int main(void) {
volatile int y;
int x;
y =
--- Comment #8 from ktietz at gcc dot gnu dot org 2009-02-18 14:23 ---
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > (In reply to comment #4)
> > > > ok, I found the issue, which causes here the problem.
> > > > The x86_64 abi returns TFmode in ra
--- Comment #4 from ubizjak at gmail dot com 2009-02-18 14:15 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00825.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #7 from hjl dot tools at gmail dot com 2009-02-18 14:13 ---
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > ok, I found the issue, which causes here the problem.
> > > The x86_64 abi returns TFmode in rax,edx which is stored in aligned s
--- Comment #11 from hjl dot tools at gmail dot com 2009-02-18 14:08
---
(In reply to comment #10)
> Please make sure the warning is issued only for appropriate languages (it is
> not
> needed in Ada for example and the wording doesn't make sense). TIA.
>
I believe that warning is tu
--- Comment #1 from manu at gcc dot gnu dot org 2009-02-18 13:15 ---
Patch submitted: http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00824.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from manu at gcc dot gnu dot org 2009-02-18 13:13 ---
Patch submitted: http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00824.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #23 from bonzini at gnu dot org 2009-02-18 13:02 ---
> Gcc doesn't know/remember
>
> movlS(,%rax,4), %eax
>
> will zero extend to 64bit. I don't know you can touch only the lower
> 32bit bits.
This could be fixed by LOAD_EXTEND_OP, right?
--
http://gcc.gnu.org/bug
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-02-18 12:56
---
Ok, a backported patch fixes all three new testcases. I was avoiding the
backport to avoid late performance and/or compile-time regressions, so I'll
give the patch (and one accompanied change that went to the bran
1 - 100 of 130 matches
Mail list logo
