--- Comment #14 from bart dot vanassche at gmail dot com 2010-04-08 06:03
---
(In reply to comment #13)
I agree it's probably not worth backporting to a release branch, it wasn't a
regression.
Haven't affected users written valgrind suppression files by now? :)
Since the races on
--- Comment #1 from jakub at gcc dot gnu dot org 2010-04-08 07:00 ---
Created an attachment (id=20331)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20331action=view)
gcc46-pr43681.patch
Untested patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43681
--- Comment #15 from dominiq at lps dot ens dot fr 2010-04-08 07:48 ---
With the patch in comment #14, the test in comment #1 compiles and gives:
evt= 234, flv= 1, col= 2, hel= 3, -0.122E-13 + i* 0.675E-14 ~ 0.267E-02
evt= 234, flv= 1, col= 2, hel= 6, -0.122E-13 +
--- Comment #4 from rguenther at suse dot de 2010-04-08 08:11 ---
Subject: Re: [4.5/4.6 Regression] ICE in s390_emit_call,
at config/s390/s390.c:9484
On Wed, 7 Apr 2010, krebbel at gcc dot gnu dot org wrote:
--- Comment #3 from krebbel at gcc dot gnu dot org 2010-04-07 15:56
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-08 08:14 ---
Mine then.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Hello,
I'm using:
ka...@thinkpad:/tmp/gcc-4.5.0-RC-20100406$ c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.5-rc0-20100412/libexec/gcc/i386-pc-solaris2.11/4.5.0/lto-wrapper
Target: i386-pc-solaris2.11
Configured with: /tmp/gcc-4.5.0-RC-20100406/configure
--- Comment #1 from kgardas at objectsecurity dot com 2010-04-08 08:16
---
Created an attachment (id=20332)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20332action=view)
preprocessed test.cc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43683
--- Comment #10 from mkuvyrkov at gcc dot gnu dot org 2010-04-08 08:20
---
Subject: Bug 40815
Author: mkuvyrkov
Date: Thu Apr 8 08:20:36 2010
New Revision: 158105
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158105
Log:
PR middle-end/40815
* tree-ssa-reassoc.c
--- Comment #11 from mkuvyrkov at gcc dot gnu dot org 2010-04-08 08:31
---
Fixed in the above revision.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||jakub at gcc dot gnu dot org
Summary|bootstrap fails with
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-08 08:39 ---
The middle-end trusts the C++ frontends TYPE_MIN/MAX_VALUE which is according
to the C++ standard the range for an (unsigned) integer type with a precision
just as wide as to represent all values in the enum.
I did
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-08 08:40 ---
Oh, and actually I don't think this bug is a wrong-code bug but at most
a quality of implementation issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43680
The following patches are proposed for both i686 and powerpc:
this is reasonably self-evident..
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00338.html
This one is in an area I've worked on - and I've checked that
-static-libgfortran is still doing its job (on i686-apple-darwin9).
--- Comment #2 from iains at gcc dot gnu dot org 2010-04-08 08:59 ---
(In reply to comment #1)
Created an attachment (id=20331)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20331action=view) [edit]
gcc46-pr43681.patch
Untested patch.
yes, thanks that works.
- I couldn't see
--- Comment #7 from manu at gcc dot gnu dot org 2010-04-08 09:02 ---
(In reply to comment #1)
Don't we already have a warning that warns about assigning values outside the
range of an enum?
pr43680.C:14:26: warning: the result of the conversion is unspecified because
â5â is
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-08 09:11 ---
Unfolded *g_7 from PRE. I have a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43679
--- Comment #5 from jakub at gcc dot gnu dot org 2010-04-08 09:16 ---
Subject: Bug 43670
Author: jakub
Date: Thu Apr 8 09:16:28 2010
New Revision: 158108
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158108
Log:
PR debug/43670
* cfgexpand.c (expand_debug_expr):
--- Comment #6 from jakub at gcc dot gnu dot org 2010-04-08 09:18 ---
Subject: Bug 43670
Author: jakub
Date: Thu Apr 8 09:17:52 2010
New Revision: 158109
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158109
Log:
PR debug/43670
* cfgexpand.c (expand_debug_expr):
--- Comment #5 from krebbel at gcc dot gnu dot org 2010-04-08 09:23 ---
(In reply to comment #4)
The extra cast happens if the function signatures are not compatible
(by means of useless_type_conversion_p).
Ok. Do you know why that behavior changed between gcc 4.4 and 4.5?
Is there
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-04-08 09:23
---
43627 is fallout and would need to be backported as well.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from carrot at gcc dot gnu dot org 2010-04-08 09:27 ---
Subject: Bug 41653
Author: carrot
Date: Thu Apr 8 09:27:44 2010
New Revision: 158110
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158110
Log:
PR target/41653
* config/arm/arm.c
--- Comment #10 from carrot at google dot com 2010-04-08 09:29 ---
Fixed by the above patch.
--
carrot at google dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2010-04-08 09:32
---
I don't think anybody is making promises that profile mode works everywhere...
Anyway, CC-ing Silvius.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #15 from paolo dot carlini at oracle dot com 2010-04-08 09:33
---
Re-open to..
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #16 from paolo dot carlini at oracle dot com 2010-04-08 09:33
---
unassign myself
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #17 from paolo dot carlini at oracle dot com 2010-04-08 09:34
---
.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-08 09:40 ---
I can't seem to be able to reproduce this with r158106. How did you configure?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from paolo dot carlini at oracle dot com 2010-04-08 09:44
---
We may make progress on this for 4.6.0, but I don't make promises. If, after
having studied the relevant bits of the Standard and the current implementation
of these features (I remind you that this is Free
--- Comment #2 from schwab at linux-m68k dot org 2010-04-08 09:45 ---
configured by ../gcc/configure, generated by GNU Autoconf 2.64,
with options '--prefix=/usr' '--build=x86_64-linux' '--enable-shared'
'--enable-threads=posix' '--with-system-zlib' '--enable-__cxa_atexit'
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-08 10:00 ---
(In reply to comment #5)
(In reply to comment #4)
The extra cast happens if the function signatures are not compatible
(by means of useless_type_conversion_p).
Ok. Do you know why that behavior changed
--- Comment #3 from jakub at gcc dot gnu dot org 2010-04-08 10:12 ---
Subject: Bug 43681
Author: jakub
Date: Thu Apr 8 10:12:35 2010
New Revision: 158111
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158111
Log:
PR bootstrap/43681
* expr.c
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-08 10:21 ---
Subject: Bug 43679
Author: rguenth
Date: Thu Apr 8 10:21:23 2010
New Revision: 158112
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158112
Log:
2010-04-08 Richard Guenther rguent...@suse.de
PR
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-08 10:24 ---
Works for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43677
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-08 10:26 ---
Subject: Bug 43679
Author: rguenth
Date: Thu Apr 8 10:25:57 2010
New Revision: 158113
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158113
Log:
2010-04-08 Richard Guenther rguent...@suse.de
PR
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-08 10:26 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #18 from bart dot vanassche at gmail dot com 2010-04-08 10:28
---
(In reply to comment #12)
In my opinion it's too late now, I'm not even sure a 4.4.4 will be released
any
time soon, and 4.5.0 is around the corner. But if Jon would also like to see
it
in 4.4.4 and
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00354.html (review/committal
pending)
Currently, there is no C type for INTEGER(16); I think some code could be made
more readable if one uses __int128 directly.
--
Summary: libgfortran: Consider using __int128
Product: gcc
--- Comment #19 from paolo dot carlini at oracle dot com 2010-04-08 10:33
---
Please keep in mind that nobody complained so far, over the last ~10 years, and
4.4 is close to its end of life.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40518
--- Comment #1 from steven at gcc dot gnu dot org 2010-04-08 10:37 ---
Supposed to be addressed before release except that they haven't. So let's
make it a 4.5 Regression, which it is to some degree.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from steven at gcc dot gnu dot org 2010-04-08 10:39 ---
No progress since this PR was opened. Ping.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41528
--- Comment #2 from steven at gcc dot gnu dot org 2010-04-08 10:39 ---
What happened to the patch mentioned in comment #1?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41576
--- Comment #2 from steven at gcc dot gnu dot org 2010-04-08 10:43 ---
Should LTO reject function declarations with incompatible attributes? Or should
the discovery of the attribute in one translation unit be used to update the
control flow graph in the other units (e.g. by writing out
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-04-08 10:47
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-04-08 10:47
---
Subject: Bug 43186
Author: rguenth
Date: Thu Apr 8 10:46:46 2010
New Revision: 158114
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158114
Log:
2010-04-08 Richard Guenther rguent...@suse.de
PR
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2010-04-08 10:48
---
I did want to remove that optimization at some point but people complained
that it was highly useful (the C++ FE can still set TYPE_PRECISION
accordingly if it wants to, but TYPE_MIN/MAX_VALUE cannot really be
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-08 11:01 ---
They are still there and don't work completely. There is a more complete
and proper solution in my mind but it's not implemented yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41576
--- Comment #4 from schwab at linux-m68k dot org 2010-04-08 11:04 ---
Sorry, I had a broken experimental change that I forgot to remove.
--
schwab at linux-m68k dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2010-04-08 11:09 ---
Interestingly, LTO actually tries to use the original file name:
/* Since SET does not need to be processed by LTRANS, use
the original file name and mark it with a '*' prefix so that
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-08 11:23 ---
We do have a fixup pass for this, but somehow it doesnt' work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43212
--- Comment #7 from jakub at gcc dot gnu dot org 2010-04-08 11:28 ---
Subject: Bug 43614
Author: jakub
Date: Thu Apr 8 11:28:06 2010
New Revision: 158117
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158117
Log:
Backport from mainline:
2010-04-01 Richard
--- Comment #5 from jakub at gcc dot gnu dot org 2010-04-08 11:29 ---
Subject: Bug 43607
Author: jakub
Date: Thu Apr 8 11:29:28 2010
New Revision: 158118
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158118
Log:
Backport from mainline:
2010-04-01 Richard
--- Comment #12 from jakub at gcc dot gnu dot org 2010-04-08 11:31 ---
Subject: Bug 43560
Author: jakub
Date: Thu Apr 8 11:31:00 2010
New Revision: 158119
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158119
Log:
Backport from mainline:
2010-03-29 Richard
--- Comment #8 from jakub at gcc dot gnu dot org 2010-04-08 11:34 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from jakub at gcc dot gnu dot org 2010-04-08 11:34 ---
Fixed also for 4.4.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #13 from jakub at gcc dot gnu dot org 2010-04-08 11:35 ---
Fixed also for 4.4.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #7 from jakub at gcc dot gnu dot org 2010-04-08 11:41 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-04-08 11:47
---
Subject: Bug 42956
Author: rguenth
Date: Thu Apr 8 11:47:13 2010
New Revision: 158123
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158123
Log:
2010-04-08 Richard Guenther rguent...@suse.de
PR
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-04-08 11:47
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2010-04-08 11:53 ---
Can't reproduce this with r158104.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43656
--- Comment #33 from mikpe at it dot uu dot se 2010-04-08 12:14 ---
Created an attachment (id=20333)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20333action=view)
eliminate use of _Unwind_GetRegionStart on ARM, part 1
Here's a preliminary patch to eliminate the functional
--- Comment #3 from zsojka at seznam dot cz 2010-04-08 12:21 ---
Created an attachment (id=20334)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20334action=view)
testcase that crashes in r158095
When size of arrays is changed from 64 to 1000, it fails again in r158095
--
I've found the bug working on direct threaded interpreter for PHP. Moving from
GCC 4.3 to GCC 4.4 caused a significant performance degradation. Looking into
produced assembler code I realized that GCC 4.4 doesn't replace all jmps to
indirect jmp with indirect jmp itself. The reason is the
--- Comment #2 from dnovillo at gcc dot gnu dot org 2010-04-08 12:51
---
(In reply to comment #1)
No progress since this PR was opened. Ping.
Yes, progress has been impossible until now. I expect to slowly getting some
content written in the next little while.
--
dnovillo at gcc
--- Comment #9 from bangerth at gmail dot com 2010-04-08 12:53 ---
I'm not saying we *should* apply a mask (in fact, I think that would be
silly). But we *could*, and if we did then VRP's actions might lead to
faster but not different code.
All I want to say is that VRP is a powerful
--- Comment #14 from hubicka at gcc dot gnu dot org 2010-04-08 13:14
---
Adding a simple limit on number of loop nests in recursive inlining is easy
thing to do, but I am not quite sure how useful it is (well, overall recursive
inlining tends to help only few very special benchmrks).
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-04-08 13:19
---
(In reply to comment #14)
Adding a simple limit on number of loop nests in recursive inlining is easy
thing to do, but I am not quite sure how useful it is (well, overall recursive
inlining tends to help only
--- Comment #16 from hubicka at ucw dot cz 2010-04-08 13:26 ---
Subject: Re: [4.4 Regression] A loop in
tree_unroll_loops_completely never ends
The main issue is that we are doing a very poor job in limiting the work
we do during complete unrolling (as well as leaving as
I meant to use -Wl,--wrap but accidentally just used --wrap. Notice that the
error message has turned it into -fwrap. This is confusing.
[j...@iceland tmp]$ gcc --wrap -c m.c
cc1: error: unrecognized command line option -fwrap
[j...@iceland tmp]$ gcc --version
gcc (GCC) 4.4.3 20100127 (Red Hat
--- Comment #17 from rguenther at suse dot de 2010-04-08 13:29 ---
Subject: Re: [4.4 Regression] A loop in
tree_unroll_loops_completely never ends
On Thu, 8 Apr 2010, hubicka at ucw dot cz wrote:
--- Comment #16 from hubicka at ucw dot cz 2010-04-08 13:26 ---
Subject: Re:
--- Comment #5 from carrot at google dot com 2010-04-08 13:31 ---
(In reply to comment #4)
I guess you'll have to experiment with your implementation to
see what gives the best results on a large body of code.
I will experiment on CSiBE.
--
--- Comment #1 from mikpe at it dot uu dot se 2010-04-08 13:32 ---
Duplicate of PR42621?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43686
Command line:
gfortran -fipa-reference testcase.f90
Tested revisions:
r158095 - crash
Output:
$ /mnt/svn/gcc-trunk/binary-158095-lto-fortran/bin/gfortran -fipa-reference
testcase.f90
testcase.f90: In function #8216;sub#8217;:
testcase.f90:8:0: internal compiler error: in analyze_function, at
--- Comment #1 from zsojka at seznam dot cz 2010-04-08 13:38 ---
Created an attachment (id=20335)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20335action=view)
auto-reduced testcase
reduced from gfortran.dg/subref_array_pointer_1.f90
--
--- Comment #5 from matz at gcc dot gnu dot org 2010-04-08 13:40 ---
Um, how can r138953 be the reason when (as the original report says) it's
still okay with r153685? In any case, my patch just shuffled around the
activation/non-activation of the scheduler, so if at all it exposed a
--- Comment #6 from zsojka at seznam dot cz 2010-04-08 13:48 ---
I am sorry for the confusion. The original testcase from comment #1 doesn't
fail in r153685 and 4.4.3. Later I found different testcase (comment #2) that
fails there.
--
--- Comment #20 from redi at gcc dot gnu dot org 2010-04-08 13:51 ---
You can still reduce the helgrind output with just one suppression
{
libstdcxx_std_string_race_pr40518
Helgrind:Race
fun:_ZNSs9_M_mutateEmmm
}
I'm not convinced the impact is severe, COW strings already have
--- Comment #2 from dmitry at zend dot com 2010-04-08 13:54 ---
yes. It's definitely the same issue.
The only additional note that __attribute__((hot)) doesn't fix the problem (as
I would expect tracing down optimize_bb_for_size_p()), but makes an additional
slowdown. In opposite, the
--- Comment #21 from paolo dot carlini at oracle dot com 2010-04-08 14:04
---
I'll look into backporting it tonight on condition you cease the hyperbole
^
That's why (among other reasons) I voted in favor
these two tests are failing at both m32 and m64.
FAIL: obj-c++.dg/const-str-5.mm -fgnu-runtime (test for excess errors)
Excess errors:
built-in:0:0: warning: 'MyConstantString' has a field
'MyConstantString::_contents' whose type uses the anonymous namespace
--
Summary:
--- Comment #18 from hubicka at ucw dot cz 2010-04-08 14:41 ---
Subject: Re: [4.4 Regression] A loop in
tree_unroll_loops_completely never ends
Well, I guess in addition to number of instructions after optimizing we can
also estimate number of instruction we actually
--- Comment #3 from ro at gcc dot gnu dot org 2010-04-08 14:46 ---
Mine.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc
--- Comment #4 from ro at gcc dot gnu dot org 2010-04-08 14:48 ---
Subject: Bug 43643
Author: ro
Date: Thu Apr 8 14:48:46 2010
New Revision: 158130
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158130
Log:
gcc:
PR target/43643
* config/i386/gmon-sol2.c
--- Comment #19 from matz at gcc dot gnu dot org 2010-04-08 14:50 ---
This seems rather like a hack for our not-so-capable loop unroller. The
estimator already correctly knows that much of it will be optimized away,
hence it would make more sense for the code emitter to also not emit
--- Comment #5 from ro at gcc dot gnu dot org 2010-04-08 14:51 ---
Subject: Bug 43643
Author: ro
Date: Thu Apr 8 14:50:56 2010
New Revision: 158131
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158131
Log:
gcc:
PR target/43643
* config/i386/gmon-sol2.c
avr-gcc -v
Using built-in specs.
Target: avr
Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib
--infodi--mandir=/usr/share/man --bindir=/usr/bin --libexecdir=/usr/lib
--- Comment #4 from iains at gcc dot gnu dot org 2010-04-08 15:07 ---
bootstrapped {powerpc,i686}-apple-darwin9.
this is fixed.
(other 'set but not used' issues at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43684 remain)
--
iains at gcc dot gnu dot org changed:
What
--- Comment #12 from ro at gcc dot gnu dot org 2010-04-08 15:09 ---
Subject: Bug 38085
Author: ro
Date: Thu Apr 8 15:09:17 2010
New Revision: 158133
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158133
Log:
gcc:
PR target/43643
* config/i386/gmon-sol2.c
--- Comment #6 from ro at gcc dot gnu dot org 2010-04-08 15:09 ---
Subject: Bug 43643
Author: ro
Date: Thu Apr 8 15:09:17 2010
New Revision: 158133
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158133
Log:
gcc:
PR target/43643
* config/i386/gmon-sol2.c
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-08 15:11 ---
Well, we have not properly gimplified the invalid function:
doit ()
{
char * pk;
char * pk.1;
char * pk.0;
bb 2:
pk = 0B;
bb 3:
__asm__ __volatile__(nop::m pk);
pk = pk + 1;
pk.0 = pk;
__asm__
--- Comment #7 from ro at gcc dot gnu dot org 2010-04-08 15:12 ---
Fixed for 4.4.4, 4.5.0, 4.6.0.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from ro at gcc dot gnu dot org 2010-04-08 15:13 ---
Reopen to document backport.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from ro at gcc dot gnu dot org 2010-04-08 15:14 ---
Fixed for 4.4.4, 4.5.0.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
URL|
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-08 15:18 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from zsojka at seznam dot cz 2010-04-08 15:35 ---
Created an attachment (id=20336)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20336action=view)
testcase with inlined f()
Even when the f() is declared as
static inline __attribute__((always_inline))
double
--- Comment #6 from zsojka at seznam dot cz 2010-04-08 15:38 ---
Testcase from comment #5 fails at x86_64-linux, trunk r153685, r158095.
It doesn't fail in the 4.4 branch.
--
zsojka at seznam dot cz changed:
What|Removed |Added
--- Comment #10 from jason at gcc dot gnu dot org 2010-04-08 15:57 ---
@7: But -Wconversion only warns if it knows the constant value, it doesn't warn
about converting from an arbitrary int variable such as (importantly) a loop
counter.
@5: It seems appropriate to me for VRP to
--- Comment #2 from sterling_augustine at tensilica dot com 2010-04-08
16:05 ---
(Removed Bob Wilson who is no longer maintaining the Xtensa port.)
This problem was actually a limitation in the gnu assembler, and is fixed
there. Unfortunately, this change didn't make it into the
When this testcase, using inline assembly, is compiled with -Os, -O2, or -O3 it
segfaults. -O0 and -O1 allow it to run correctly.
Moving the inline assembly into a separate file and including it in the
compilation allow the program to run correctly at all -O levels.
My results are
gcc -O0
--- Comment #1 from mattst88 at gmail dot com 2010-04-08 16:50 ---
Created an attachment (id=20337)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20337action=view)
rewritten.S - external assembly
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43691
--- Comment #2 from mattst88 at gmail dot com 2010-04-08 16:50 ---
Created an attachment (id=20338)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20338action=view)
test.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43691
1 - 100 of 175 matches
Mail list logo
