--- Comment #8 from howarth at nitro dot med dot uc dot edu 2009-01-16
08:14 ---
Regressing r143152 from current gcc trunk also eliminates the problem
confirming that commit is the origin of the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-16 09:23 ---
I think you should simply do the check for an indirect base only if the folding
of the view-convert-expr ended up in a view-convert-expr. Playing with
alias-sets
here will still cause these nested v-c-es with
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-16 09:27 ---
If you wouldn't generate a V_C_E for *(float*)sv-i it would just work.
IMHO this should be invalid gimple anyway, as you V_C_E a register type but
the V_C_E argument is not a register. Thus valid gimple would be
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-01-16 09:34
---
Do we have a small testcase?
VIEW_CONVERT_EXPRunion u_u64(c64_76).u.lo32.u.lo16.u.lo8 = D.1947_8;
indeed looks funny (it's a partial def of a register).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38745
--- Comment #4 from rguenther at suse dot de 2009-01-16 09:36 ---
Subject: Re: missing FRE with
VIEW_CONVERT_EXPR
On Fri, 16 Jan 2009, pinskia at gcc dot gnu dot org wrote:
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-16 02:33
---
Mine. Simple patch which
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-01-16 09:42 ---
I tried to reproduce this on i686-linux without success (-O3 -fPIC -mfpmath=sse
-msse2 -m32).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
--- Comment #5 from janus at gcc dot gnu dot org 2009-01-16 09:42 ---
Further test cases:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/e0d04d755453a2a5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36704
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-16 09:57 ---
I think this boils down to the usual POINTER_PLUS fallout.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38856
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-16 10:00 ---
This is at most a documentation problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38864
--- Comment #10 from dominiq at lps dot ens dot fr 2009-01-16 10:00 ---
I don't see any problem on powerpc-apple-darwin9, but I confirm it on
i686-apple-darwin9 on 32 bit mode. The problem disappear with either -m64
and/or -fno-pic.
--
--- Comment #3 from jakub at gcc dot gnu dot org 2009-01-16 11:21 ---
-O2 -fno-tree-pre works. tree_could_trap_p is true for integer division by
non-constant (or 0), but we don't seem to have stmt_could_trap_p. Perhaps it
should be added and PRE should considfer it? In rtl land,
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-16 11:41 ---
Optimal would be to check this at insertion time, a quick fix is to adjust
compute_avail to not consider trapping expressions.
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
Sent from my iPhone
On Jan 16, 2009, at 1:57 AM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-16
09:57 ---
I think this boils down to the usual POINTER_PLUS fallout.
It failed in 4.1 also so nope
--- Comment #6 from pinskia at gmail dot com 2009-01-16 11:46 ---
Subject: Re: loop iv detection failure
Sent from my iPhone
On Jan 16, 2009, at 1:57 AM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #5 from rguenth at gcc dot gnu dot org
I just tried to compile this file with the GNU C compiler
version 4.4 snapshot 20090109 using valgrind and the flags
-O3 march=native on a amd64 box.
The debug output was
==20395== Invalid read of size 2
==20395==at 0xAFDA6E: T.911 (ira-costs.c:590)
==20395==by 0xAFE0F0: T.910
--- Comment #10 from janus at gcc dot gnu dot org 2009-01-16 12:04 ---
Subject: Bug 38152
Author: janus
Date: Fri Jan 16 12:03:51 2009
New Revision: 143430
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143430
Log:
2009-01-16 Janus Weil ja...@gcc.gnu.org
PR
taking into account the following program
-
class tester {
public:
int i;
void foo() {}
};
int main()
{
tester().foo();
tester().i = 10;
return 0;
}
-
The C++
--- Comment #1 from stefan dot constantin at gmail dot com 2009-01-16
12:07 ---
Sorry for not mentioning this earlier,
the sample program provide compiles without error or warning with
g++ -Wall.
I expected the compiler to error on the line tester().i = 10; because such a
construct
--- Comment #11 from janus at gcc dot gnu dot org 2009-01-16 12:30 ---
This PR can be closed, provided there are no remaining issues on darwin9 (see
comment #4 and #5). I cannot check this myself (since I don't have access to a
darwin system), but maybe Dominique can?
--
janus at
--- Comment #7 from jakub at gcc dot gnu dot org 2009-01-16 12:42 ---
The correct testcase is IMHO:
void
baz (int v)
{
unsigned a = (v == 1) ? 1 : 2;
if (__builtin_constant_p (a))
asm volatile (# constant %0 :: i (a));
else
asm volatile (# register %0 :: r (a));
}
For
--- Comment #8 from jakub at gcc dot gnu dot org 2009-01-16 12:49 ---
Yes, it does. Going to bootstrap/regtest it now.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-01-16 13:20 ---
Now it does. See PR38835.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-01-16 13:35 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-16 13:36 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dave dot korn dot cygwin at gmail dot com 2009-01-16
13:41 ---
(In reply to comment #5)
If you look at the (static) libgcc.a, when shared libs are enabled, it
contains only symbols that are not exported from the shared dll. Only the
'API-stable' symbols are
--- Comment #6 from dave dot korn dot cygwin at gmail dot com 2009-01-16
13:43 ---
This bug is fixed and should be closed now. A new PR, bug 37660, has been
created for the separate issue in comment 4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37915
While comparing list of gcc 4.3 and 4.4 library exported symbols, I've
discovered that libgfortran.so.3 dropped
__iso_c_binding_c_f_procpointer@@GFORTRAN_1.0
but hasn't changed SONAME. That's an ABI break. Could we get the symbol back
for compatibility with gfortran 4.3?
--
--- Comment #1 from hjl dot tools at gmail dot com 2009-01-16 14:18 ---
Where is the input file?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
While comparing list of exported symbols, libgcj_bc.so.1 hasn't dropped any
symbols from 4.3 (correct, hasn't changed SONAME), but libgcj.so.10 dropped
_Jv_CreateJavaVM and _Jv_GetStringChars symbols compared to libgcj.so.9.
That wouldn't normally be an issue (they have different SONAME), but in
--- Comment #2 from jakub at gcc dot gnu dot org 2009-01-16 14:27 ---
Also for -march=native you should really post what -fverbose-asm tells you has
been selected for -march and other option (and you should retry with those
options instead of -march=native).
--
--- Comment #3 from jv244 at cam dot ac dot uk 2009-01-16 14:38 ---
(In reply to comment #2)
Also for -march=native you should really post what -fverbose-asm tells you has
been selected for -march and other option (and you should retry with those
options instead of -march=native).
I'm trying to compile boost 1.37.0 on Slackware 12.1 and get an internal
compiler error on trying to compile comp_ellint_1l.cpp. I have Slackware's
stock gcc, which is 4.2.3.
The exact command that triggers the error is:
/usr/bin/g++ -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall
--- Comment #1 from HMWiesinger at gmx dot at 2009-01-16 14:45 ---
Created an attachment (id=17117)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17117action=view)
preprocessed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38873
--- Comment #4 from hjl dot tools at gmail dot com 2009-01-16 14:59 ---
(In reply to comment #3)
(In reply to comment #2)
Also for -march=native you should really post what -fverbose-asm tells you
has
been selected for -march and other option (and you should retry with those
--- Comment #1 from aph at gcc dot gnu dot org 2009-01-16 14:59 ---
Thanks for looking.
As far as I can see _Jv_GetStringChars has been extern inline forever, so
doesn't matter. Probably should have a matching definition, but will never be
called.
_Jv_CreateJavaVM in libgcj.so.9 is:
--- Comment #23 from r dot emrich at de dot tecosim dot com 2009-01-16
15:01 ---
Created an attachment (id=17118)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17118action=view)
fix file magic regex for hppa*64*
This patch fixes the file magic regex for hppa*64*.
All dependent
--- Comment #9 from jakub at gcc dot gnu dot org 2009-01-16 15:01 ---
Subject: Bug 38789
Author: jakub
Date: Fri Jan 16 15:01:24 2009
New Revision: 143435
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143435
Log:
PR tree-optimization/38789
* tree-ssa-threadedge.c
--- Comment #10 from jakub at gcc dot gnu dot org 2009-01-16 15:02 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #24 from rwild at gcc dot gnu dot org 2009-01-16 15:13 ---
(In reply to comment #23)
This patch fixes the file magic regex for hppa*64*.
All dependent files have to be regenerated.
This modified regex allows to detect PA-RISC shared objects with the native
HP-UX file
--- Comment #25 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-16
15:14 ---
Subject: Re: fails to build cross gcc for target hppa64-hp-hpux11.00 in
libstdc++/libmath
Created an attachment (id=17118)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17118action=view)
--
When trying make check
RUNTESTFLAGS=--target_board='unix/{,-fstack-protector/--param=ssp-buffer-size=4}'
I've noticed all gnat.dg tests fail as gnatmake doesn't pass through --param
options.
I see it already special cases (most of) -m*, -f*, -g* etc. options,
could it do the same for --param?
As
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2009-01-16
15:27 ---
I've not had any luck reproducing this issue on linux. A few other notes. I
don't see this problem with the Macintel gfortran binaries from...
http://gcc.gnu.org/wiki/GFortranBinaries
However those may
--- Comment #1 from laurent at guerby dot net 2009-01-16 15:33 ---
for the --param= case the following should work (untested):
Index: gcc/ada/make.adb
===
--- gcc/ada/make.adb(revision 143273)
+++ gcc/ada/make.adb
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2009-01-16
15:33 ---
Any ideas on how to debug this further locally? If I add,,,
--- testcase.f.org 2009-01-16 10:28:14.0 -0500
+++ testcase.f 2009-01-16 10:28:47.0 -0500
@@ -194,5 +194,6 @@
Hi,
I recently started using the paralleled version of gcc's libstdc++. Now, I have
recognized that there is no parallel version of the fill algorithm (at least at
i486-linux-gnu).
The threshold variable __gnu_parallel::_Settings::fill_minimal_n
suggests that a parallel version of the fill
--- Comment #2 from laurent at guerby dot net 2009-01-16 15:37 ---
Oops == = =
Index: gcc/ada/make.adb
===
--- gcc/ada/make.adb(revision 143273)
+++ gcc/ada/make.adb(working copy)
@@ -8039,6 +8039,7 @@
--- Comment #1 from paolo dot carlini at oracle dot com 2009-01-16 15:46
---
Thanks for your report. Johannes, can you have a look?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875
--- Comment #2 from singler at gcc dot gnu dot org 2009-01-16 15:51 ---
In some former (non-integrated) version of the code we had problems with fill
because it was so heavily used by other routines of the STL. But this is not a
principal problem. So I will try to integrate it as soon
--- Comment #5 from dcb314 at hotmail dot com 2009-01-16 15:54 ---
(In reply to comment #1)
Where is the input file?
gcc/testsuite/gcc.dg/callabi/func-1.c
My apologies for not getting the cut'n'paste correct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38869
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ABI
Priority|P3 |P1
Target
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ABI
Priority|P3 |P1
Target
--- Comment #26 from r dot emrich at de dot tecosim dot com 2009-01-16
16:07 ---
(In reply to comment #24)
(In reply to comment #23)
This patch fixes the file magic regex for hppa*64*.
All dependent files have to be regenerated.
This modified regex allows to detect PA-RISC
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-16 16:07 ---
Works for me. Can you specify the output of the g++ command if you append -v
to
the full commandline?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38873
--- Comment #1 from kargl at gcc dot gnu dot org 2009-01-16 16:13 ---
Jakub probably already knows this, but
2008-05-25 Tobias Burnus bur...@net-b.de
PR fortran/32600
* intrinsics/iso_c_binding.c (c_f_procpointer): Remove.
* intrinsics/iso_c_binding.h
--- Comment #27 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-16
16:15 ---
Subject: Re: fails to build cross gcc for target hppa64-hp-hpux11.00 in
libstdc++/libmath
Changes to libtool.m4 should be posted upstream (to the libtool-patches at
gnu.org list) and integrated there
--- Comment #28 from r dot emrich at de dot tecosim dot com 2009-01-16
16:17 ---
Created an attachment (id=17119)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17119action=view)
fix file magic regex for hppa*64*
updated patch
--
r dot emrich at de dot tecosim dot com changed:
--- Comment #2 from jakub at gcc dot gnu dot org 2009-01-16 16:26 ---
Then that patch was wrong. You could have code compiled with gfortran 4.3 that
references this symbol, which won't even start (e.g. with LD_BIND_NOW=1)
against gcc 4.4 libgfortran.
The symbol needs to be IMHO put
--- Comment #29 from r dot emrich at de dot tecosim dot com 2009-01-16
16:45 ---
Created an attachment (id=17120)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17120action=view)
fix file magic regex for HP-UX hosts
updated patch for all HP-UX hosts.
--
r dot emrich at de dot
--- Comment #30 from r dot emrich at de dot tecosim dot com 2009-01-16
16:51 ---
(In reply to comment #21)
I dont't know if the warnings at the end of this message are a result of this
issue or different one. The linker complains about fde encoding in
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-16 17:13 ---
The patch mail says
As c_f_procpointer was never callable, I could remove it from the library.
so it was never used?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38871
--- Comment #31 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-16
17:21 ---
Subject: Re: fails to build cross gcc for target hppa64-hp-hpux11.00 in
libstdc++/libmath
I dont't know if the warnings at the end of this message are a result of
this
issue or different one. The
I have seen bug 21198. My understanding is that refers to an operating system
limit on the number of simultaneous files open. However if we attempt to reuse
the same stream using fclose to close it before fopen is called again
we still hit a limit. Under gentoo gcc runtime fails to open the file
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-16 18:05 ---
close is not fclose. close works on file numbers and not FILE*.
t.c:4: warning: return type defaults to 'int'
t.c: In function 'main':
t.c:13: warning: format '%0x' expects type 'unsigned int', but argument 3 has
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-16 18:22 ---
return reinterpret_cast_Tp*(reinterpret_cast_UIntPtrType(this)
+ _M_diff);
(const struct _Fwd_list_node_base *) this p+ (long unsigned int) ((const
struct
--- Comment #3 from rguenther at suse dot de 2009-01-16 18:27 ---
Subject: Re: field-insensitive PTA causes
libstdc++ miscompiles
On Fri, 16 Jan 2009, pinskia at gcc dot gnu dot org wrote:
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-16 18:22
---
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-16 18:30 ---
void *p;
intptr_t iptr = (intptr_t)p - (intptr_t)iptr;
of course. Then this is just
(void *)((intptr_t)iptr + (intptr_t)p - (intptr_t)iptr)
==
(void *)(intptr_t)p
which is guaranteed by the std
--
--- Comment #32 from r dot emrich at de dot tecosim dot com 2009-01-16
18:33 ---
(In reply to comment #31)
Probably, the warning needs to be suppressed. The warning is correct
in that the encoding currently used contains dynamic relocations
preventing the creation of a
On Fri, Jan 16, 2009 at 10:30 AM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:
(void *)((intptr_t)iptr + (intptr_t)p - (intptr_t)iptr)
==
(void *)(intptr_t)p
which is guaranteed by the std
No that is not guaranteed because of:
If the result cannot be represented in the
--- Comment #5 from pinskia at gmail dot com 2009-01-16 18:33 ---
Subject: Re: field-insensitive PTA causes libstdc++ miscompiles
On Fri, Jan 16, 2009 at 10:30 AM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:
(void *)((intptr_t)iptr + (intptr_t)p - (intptr_t)iptr)
--- Comment #7 from jason at gcc dot gnu dot org 2009-01-16 18:35 ---
Subject: Bug 38579
Author: jason
Date: Fri Jan 16 18:35:28 2009
New Revision: 143439
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143439
Log:
PR c++/38579
* search.c (protected_accessible_p):
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-01-16 18:37 ---
Guaranteed by 7.18.1.4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38835
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-01-16 18:41 ---
A regression because POINTER_PLUS_EXPR is new with 4.3.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
On Fri, Jan 16, 2009 at 10:37 AM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-01-16 18:37
---
Guaranteed by 7.18.1.4.
These types are optional.
:)
--- Comment #8 from pinskia at gmail dot com 2009-01-16 18:44 ---
Subject: Re: field-insensitive PTA causes libstdc++ miscompiles
On Fri, Jan 16, 2009 at 10:37 AM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:
--- Comment #6 from rguenth at gcc dot gnu dot org
--- Comment #2 from william dot langdon at kcl dot ac dot uk 2009-01-16
18:45 ---
(In reply to comment #1)
Yip, fclose fixes it!
Many thanks!
Bill
Ps: gcc did not give any warnings here, unless I add -Wall
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38876
--- Comment #9 from rguenther at suse dot de 2009-01-16 18:51 ---
Subject: Re: [4.4 Regression] field-insensitive
PTA causes libstdc++ miscompiles
On Fri, 16 Jan 2009, pinskia at gmail dot com wrote:
--- Comment #8 from pinskia at gmail dot com 2009-01-16 18:44 ---
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-01-16 18:53 ---
Here is a testcase where IV can be found but we end up with two copies of the
same register in the loop:
int f(unsigned long s, unsigned long *c)
{
long j;
for(j = 0;j s; j++)
{
c[j]=j;
}
}
Which
--- Comment #8 from jason at gcc dot gnu dot org 2009-01-16 18:55 ---
Fixed for 4.4, not applying to older branches.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-01-16 18:55 ---
If you wouldn't generate a V_C_E for *(float*)sv-i it would just work.
The front-end generates them for the vector testcase which is why I added that
one to show that forwprop does not matter in the end.
--
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-01-16 18:56
---
C testcase, fails with 4.3 and 4.4 with -O2 --param
max-fields-for-field-sensitive=0
#include stdint.h
extern void abort (void);
int main()
{
int i = 1;
int *p = i;
uintptr_t iptr;
iptr = (uintptr_t)p -
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-01-16 18:56
---
C testcase, fails with 4.3 and 4.4 with -O2 --param
max-fields-for-field-sensitive=0
#include stdint.h
extern void abort (void);
int main()
{
int i = 1;
int *p = i;
uintptr_t iptr;
iptr = (uintptr_t)p -
--- Comment #5 from nemet at gcc dot gnu dot org 2009-01-16 18:57 ---
Subject: Bug 38554
Author: nemet
Date: Fri Jan 16 18:56:47 2009
New Revision: 143440
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143440
Log:
PR target/38554
* expmed.c (expand_shift): With
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-01-16 18:57
---
*** This bug has been marked as a duplicate of 36227 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from nemet at gcc dot gnu dot org 2009-01-16 18:57 ---
Fixed.
--
nemet at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-01-16 18:57
---
*** Bug 38835 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36227
--- Comment #2 from jason at gcc dot gnu dot org 2009-01-16 18:58 ---
*** This bug has been marked as a duplicate of 38579 ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jason at gcc dot gnu dot org 2009-01-16 18:58 ---
*** Bug 35640 has been marked as a duplicate of this bug. ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-01-16 18:59 ---
Here is another testcase but this time without - :
struct s { int i; };
void g(struct s *);
float a (void)
{
struct s sv;
sv.i = 0;
int d = sv.i;
float d1 = *(float*)d;
g(sv);
return d1;
}
float a1
=gnu --with-system-zlib --with-demangler-in-ld --enable-shared
--enable-threads=posix --enable-haifa --enable-checking
--enable-languages=c,c++ --disable-bootstrap
Thread model: posix
gcc version 4.4.0 20090116 (experimental) [trunk revision 143437] (GCC)
[...@gnu-27 build_base_o3.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38877
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-01-16 19:18
---
Subject: Bug 36227
Author: rguenth
Date: Fri Jan 16 19:18:18 2009
New Revision: 143442
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143442
Log:
2009-01-16 Richard Guenther rguent...@suse.de
PR
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-01-16 19:18
---
Subject: Bug 38835
Author: rguenth
Date: Fri Jan 16 19:18:18 2009
New Revision: 143442
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143442
Log:
2009-01-16 Richard Guenther rguent...@suse.de
PR
We do not fold
(long int) ((long unsigned int) b + 5) == (long int) b
--
Summary: [4.4 Regression] gcc.dg/tree-ssa/foldaddr-1.c XFAILed
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: xfail
Severity: normal
Currently, following test fails on alpha target:
FAIL: gfortran.fortran-torture/execute/intrinsic_len.f90 execution, -O2
-fomit-frame-pointer -finline-functions -funroll-loops
This is due to generic scheduler problem, where scheduler doesn't care about
conflictig memory alias sets.
The problem
We do not fold
(long int) 16B-y - 16
--
Summary: [4.4 Regression] g++.dg/init/const7.C XFAILed
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: xfail
Severity: normal
Priority: P3
Component:
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-01-16 19:22
---
Fixed on the trunk. Also fails with plain -O for 4.3.2.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-16 19:23 ---
Caused by the fix for PR36227.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-16 19:23 ---
Caused by the fix for PR36227.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38880
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38878
1 - 100 of 191 matches
Mail list logo
