--- Comment #8 from sabre at nondot dot org 2009-12-29 06:07 ---
Clang does not produce diagnostics from the optimizer. We intentionally do not
want to do this, because of the fragility of the diagnostics as the optimizer
evolves. IMO it is much better to produce a consistent and predi
--- Comment #1 from hjl dot tools at gmail dot com 2009-12-29 05:10 ---
I also saw it on Linux/x86-64. It is caused by revision 154561:
http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00784.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Ad
--- Comment #3 from davek at gcc dot gnu dot org 2009-12-29 04:13 ---
Subject: Bug 41595
Author: davek
Date: Tue Dec 29 04:13:09 2009
New Revision: 155500
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155500
Log:
2009-10-06 Iain Sandoe
PR objective-c++/41595
--- Comment #15 from jason at gcc dot gnu dot org 2009-12-29 03:33 ---
Subject: Bug 42447
Author: jason
Date: Tue Dec 29 03:33:24 2009
New Revision: 155499
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155499
Log:
PR c++/42447
* pt.c (iterative_hash_template_arg
--- Comment #1 from davek at gcc dot gnu dot org 2009-12-29 02:53 ---
Created an attachment (id=19408)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19408&action=view)
Avoid emitting asterisk in assembler section directives.
Several other places in lto-streamer-out.c take this sam
GCC: h...@155348, i686-pc-cygwin native, libelf-0.8.13:
> > FAIL: gcc.c-torture/compile/2009-1.c (test for excess errors)
> > Excess errors:
> > /win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/cccnrdgl.s:13: Error: junk at end of
> > line, first unrecognized character is `*'
Looking at the generated
--- Comment #4 from urbanjost at comcast dot net 2009-12-29 02:50 ---
Subject: Re: Fortran FORMAT descriptor "X" generates nulls instead of blanks
for ACCESS='stream" files
No, I didn't build this compiler version; this is what I got when I
reinstalled CygWin from scratch on 11/29/200
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-12-29 02:44
---
I confirmed that there is no problem with gfortran 4.5 on Cygwin. A binary is
available on the wiki.
http://gcc.gnu.org/wiki/GFortranBinaries
Let me know if you have any difficulties with this.
--
jvdelisle
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2009-12-29 02:27
---
Thank you for the report. I will investigate and see what I can do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42527
An svn build from 20091229 is getting an ICE when building the following code:
int array[2][2];
void foo(int *a)
{
int i, j;
int sum, tmp = 0;
for (i=0; i<2; i++)
for (j=0; j<2; j++)
sum += array[i][j];
if (sum > 0) {
--- Comment #6 from ami_stuff at o2 dot pl 2009-12-29 01:20 ---
> Works for me with 4.5.0 20091228.
How's that possible? What about GCC 4.4 branch? I just checked with ATARI GCC
4.4.2 m68k compiler and got the same result:
/usr/local/cross-mint/bin/m68k-atari-mint-gcc -c -S f
--- Comment #1 from kargl at gcc dot gnu dot org 2009-12-29 00:37 ---
> Driving: gfortran -v missouri.f -o missouri -lgfortranbegin -lgfortran
> -shared-libgcc
> Using built-in specs.
> Target: i686-pc-cygwin
> Configured with: /gnu/gcc/package/gcc4-4.3.2-2/src/gcc-4.3.2/configure
Thi
--- Comment #4 from mckelvey at maskull dot com 2009-12-28 23:58 ---
Correction, I used the cygwin compiler to bootstrap this time.
$ /usr/bin/gcc.exe -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with:
/gnu/gcc/releases/packaging/4.3.4-3/gcc4-4.3.4-3/src/gcc-4.3.4/configur
--- Comment #3 from mckelvey at maskull dot com 2009-12-28 23:54 ---
$ report.sh
uname -a
CYGWIN_NT-5.1 MCKELVEY-XP 1.7.1(0.218/5/3) 2009-12-07 11:48 i686 Cygwin
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-cygwin/4.5.0/lto-wrapper.exe
--- Comment #2 from mckelvey at maskull dot com 2009-12-28 23:53 ---
Created an attachment (id=19407)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19407&action=view)
config.log from point of error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42529
--- Comment #1 from mckelvey at maskull dot com 2009-12-28 23:52 ---
Created an attachment (id=19406)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19406&action=view)
Build log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42529
xgcc returns status of 1 without producing an object file and declares no
errors.
checking for i686-pc-cygwin-gcc... /cygdrive/e/Home/cvsroot/gcc-obj/./gcc/xgcc
-B/cygdrive/e/Home/cvsroot/gcc-obj/./gcc/ -B/usr/local/i686-pc-cygwin/bin/
-B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-
--- Comment #5 from ami_stuff at o2 dot pl 2009-12-28 23:38 ---
I found which optimization doesn't work correctly on my config:
-O2 ("Unknown format"):
_flv_probe:
clr.l d0
rts
.even
-O2 -fno-cse-follow-jumps (works OK):
_flv_probe:
move.l 4(sp),a0
--- Comment #4 from schwab at linux-m68k dot org 2009-12-28 23:30 ---
Works for me with 4.5.0 20091228.
--
schwab at linux-m68k dot org changed:
What|Removed |Added
--- Comment #4 from debian-gcc at lists dot debian dot org 2009-12-28
23:27 ---
my bad. my backport of pr40134 still had the chunk to
gcc/config/rs600/rs6000.c, which was part of a patch for the trunk.
sorry, Matthias
--
debian-gcc at lists dot debian dot org changed:
W
--- Comment #16 from janus at gcc dot gnu dot org 2009-12-28 23:16 ---
Fixed with r155494. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from janus at gcc dot gnu dot org 2009-12-28 23:13 ---
Subject: Bug 42353
Author: janus
Date: Mon Dec 28 23:13:03 2009
New Revision: 155494
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155494
Log:
gcc/fortran/
2009-12-28 Janus Weil
PR fortran/42353
--- Comment #3 from ljrittle at gcc dot gnu dot org 2009-12-28 23:08
---
Mainline (4.5) was logically sync'd to FreeBSD 7.x configuration at the end of
summer 2009
with alternate patches.
--
ljrittle at gcc dot gnu dot org changed:
What|Removed |A
--- Comment #2 from ljrittle at gcc dot gnu dot org 2009-12-28 23:07
---
Fixed with alternate patch that went into mainline (4.5) at end of summer 2009.
--
ljrittle at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from ljrittle at gcc dot gnu dot org 2009-12-28 23:05
---
Alternate patch was generated and installed on mainline (4.5) to address lack
of support for dl_iterate_phdr from FreeBSD 7.0 libc.
--
ljrittle at gcc dot gnu dot org changed:
What|Removed
A gcc build from svn today (20091228) gets an ICE on the following code when
using -flto and -fsigned-char:
char *foo;
int main()
{
foo = "bar";
}
# /gcc-test/bin/gcc -flto -fsigned-char foo.c
In function 'main':
lto1: error: type mismatch in address expression
--- Comment #3 from hjl dot tools at gmail dot com 2009-12-28 22:52 ---
It is caused by the new implementation of Graphite:
http://gcc.gnu.org/ml/gcc-cvs/2009-07/msg01187.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
I can't get the newest gfortran version to run on my platform (CygWin/Vista);
but have
a very small reproducer and could not find this one listed in Bugzilla.
#!/bin/sh
cat >missouri.f <<\EOF
!ccc
! 1x in format is generating a nu
--- Comment #14 from anlauf at gmx dot de 2009-12-28 22:39 ---
(In reply to comment #13)
> Sorry, I'm unable to reproduce this ICE on x86_64-unknown-linux-gnu with the
> trunk at r155493, neither with the patch in comment #8 nor without.
My mistake, I applied the patch to the same gcc t
If the testcase gfortran.dg/char_component_initializer_1.f90 is compiled with
-Wall, a bogus truncation warning is given:
$> gfortran-svn -Wall gfortran.dg/char_component_initializer_1.f90
gfortran.dg/char_component_initializer_1.f90:11.52:
character(len=16) :: tdefi(2) = (/'0z1jan','1hr
--- Comment #13 from janus at gcc dot gnu dot org 2009-12-28 21:59 ---
(In reply to comment #12)
> I have attached a version that results in the following ICE after your patch
> was applied. The error message reads:
>
> gfcbug96c.f90:144:0: internal compiler error: Segmentation fault
--- Comment #1 from bjg at gnu dot org 2009-12-28 21:48 ---
Created an attachment (id=19405)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19405&action=view)
complete build log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42524
gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition
-Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -o
build/gengtype \
build/gengtype.o build/gengtype-lex.o build/gengt
--- Comment #12 from anlauf at gmx dot de 2009-12-28 21:44 ---
Created an attachment (id=19404)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19404&action=view)
Sample code for ICE
Janus,
I have attached a version that results in the following ICE after your patch
was applied. T
Doing a complete build from scratch fails with the following error on the gcj
link step.
~/ftp/gcc-4.4.2/configure --prefix=/gd/gnu/gnusys/live/
--with-mpfr=/gd/gnu/gnusys/live --with-gmp=/gd/gnu/gnusys/live
libtool: link: ar rc .libs/libgcj_bc.a libgcj_bc.o
libtool: link: ranlib .libs/libgcj_bc
--- Comment #14 from janus at gcc dot gnu dot org 2009-12-28 21:41 ---
*** Bug 42484 has been marked as a duplicate of this bug. ***
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from janus at gcc dot gnu dot org 2009-12-28 21:41 ---
*** This bug has been marked as a duplicate of 41344 ***
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
-
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
The freestanding flag should make gcc forget about special function names
and, specifically about the main() entry point. Anyway, gcc generates
different code for two source files that differ only in the name of a function,
beeing this name "main" in one of them.
When one of the functions in the s
--- Comment #49 from steven at gcc dot gnu dot org 2009-12-28 20:46 ---
For hashes100.c, combine+IRA+expand+tree-PRE accounts for 1/3 of the total
compile time. For infcodes100.c, the profile is more flat, but IRA+expand still
account for 1/4 of the total compile time.
Why is IRA so slo
--- Comment #48 from steven at gcc dot gnu dot org 2009-12-28 20:39 ---
Created an attachment (id=19403)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19403&action=view)
profile for cc1 r155486 on x86_64, options -O2, for hashes100.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #47 from steven at gcc dot gnu dot org 2009-12-28 20:38 ---
Created an attachment (id=19402)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19402&action=view)
profile for cc1 r155486 on x86_64, options -O2, for infcodes100.c
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #3 from ami_stuff at o2 dot pl 2009-12-28 20:38 ---
No, asm code looks the same like with -O2 option:
_flv_probe:
clr.l d0
rts
.even
Here are GCC's options which I used (should be included in the first post):
$ make_68k_v45
/bin/ffmpeg13_play/versi
--- Comment #46 from steven at gcc dot gnu dot org 2009-12-28 20:35 ---
Same thing for hashes100.c (profile in comment #45 is for infcodes100.c), in
both cases cc1 r155486 at -O2 on x86_64):
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self
--- Comment #45 from steven at gcc dot gnu dot org 2009-12-28 20:28 ---
Profile for cc1 for SVN r155486 looks like this (all items with >0.5% time):
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds secondscalls
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-12-28 20:23 ---
Does -O2 -fno-strict-aliasing work?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from zsojka at seznam dot cz 2009-12-28 20:17 ---
Compiler flags can be further reduced to:
-O1 -funswitch-loops -fstrict-aliasing -fgraphite-identity
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42521
--- Comment #1 from ami_stuff at o2 dot pl 2009-12-28 20:17 ---
Created an attachment (id=19401)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19401&action=view)
preprocessed files + asm output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42522
Hi,
This is a code from "libavformat/flvdec.c":
static int flv_probe(AVProbeData *p)
{
const uint8_t *d;
d = p->buf;
if (d[0] == 'F' && d[1] == 'L' && d[2] == 'V' && d[3] < 5 && d[5]==0 &&
AV_RB32(d+5)>8) {
return AVPROBE_SCORE_MAX;
}
return 0;
}
When I compile FFmpe
--- Comment #1 from zsojka at seznam dot cz 2009-12-28 20:10 ---
Created an attachment (id=19400)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19400&action=view)
reduced testcase
Command line:
gcc -O3 -fgraphite-identity -c pr42521.c
--
http://gcc.gnu.org/bugzilla/show_bug.c
Command line:
gcc -O3 -fgraphite-identity -c testcase.c
Tested versions:
trunk r155434 - crash
trunk r155363 - crash (with and without checking)
trunk r155248 - crash
trunk r154830 - crash
trunk r153685 - different crash (in build_loop_iteration_domains)
4,4 r155365 - OK
4.4 r154975 - OK (with che
--- Comment #44 from steven at gcc dot gnu dot org 2009-12-28 19:51 ---
hashes100.c on x86_64:
3.4.6 4.2.4 4.3.3 4.4.2 4.5.0
-O0 1.371.4 1.591.911.84
-O1 2.074 4.444.684.89
-O2 3.575.967.087.487.6
-O3 3.78
--
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
For example, `gcc -march=pentium -flto -fuse-linker-plugin main.c' causes this:
/usr/local/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto1 -quiet -dumpbase cc0AFVJ9
-mtune=generic -march=pentium4 -auxbase-strip /tmp/cc7X43Dc.lto.o
-fuse-linker-plugin -fresolution @/tmp/ccoGGiIc -o /tmp/ccCcL0Ff.s
"-mtun
--- Comment #11 from janus at gcc dot gnu dot org 2009-12-28 19:13 ---
(In reply to comment #10)
> this patch appears OK so far.
Great, thanks for checking.
> (I get a probably unrelated ICE later in the compilation process
> of the Fortran project which I am investigating).
Would be
--- Comment #10 from anlauf at gmx dot de 2009-12-28 18:35 ---
(In reply to comment #8)
> Ok, here is a new patch, which fixes all problems reported here so far:
Janus,
this patch appears OK so far.
(I get a probably unrelated ICE later in the compilation process
of the Fortran projec
--- Comment #1 from markusl dot se78 at gmail dot com 2009-12-28 17:59
---
Another solution might be to have a define_insn_and_split for a 64x64->64bit
multiply allowing the combiner to do its job combining into a widening
multiplication and if this fails the insn will later be split in
--- Comment #5 from laurent at guerby dot net 2009-12-28 17:55 ---
Yes likely a distro header bug as I said: "Now may be it's a bug in debian etch
libc headers but it would be nice to honor --disable-werror in libgomp."
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42519
--- Comment #4 from jakub at gcc dot gnu dot org 2009-12-28 17:50 ---
If Debian provides by default LinuxThread's instead of NPTL
, then it should also make sure linking with -lpthread links against
LinuxThread's libpthread.so instead of NPTL one. So this looks like a distro
bug to me.
--- Comment #3 from laurent at guerby dot net 2009-12-28 17:47 ---
"The second issue is how libgomp configure detects availability of
pthread_{attr,}_{get,set}affinity_np. It uses link test and does not pass -Wall
-Werror to compiler; thus, libgomp build fails if those functions are decl
--- Comment #2 from amonakov at gcc dot gnu dot org 2009-12-28 17:45
---
(In reply to comment #1)
> So, your pthread.h doesn't contain prototype for pthread_getaffinity_np, yet
> libpthread.so.0 exports it? Otherwise:
Affected system declares those functions in /usr/include/nptl/pthre
--- Comment #1 from jakub at gcc dot gnu dot org 2009-12-28 17:33 ---
So, your pthread.h doesn't contain prototype for pthread_getaffinity_np, yet
libpthread.so.0 exports it? Otherwise:
# Check for pthread_{,attr_}[sg]etaffinity_np.
AC_LINK_IFELSE(
[AC_LANG_PROGRAM(
[#define _GNU_SOU
--- Comment #8 from hjl at gcc dot gnu dot org 2009-12-28 17:18 ---
Subject: Bug 41305
Author: hjl
Date: Mon Dec 28 17:18:22 2009
New Revision: 155491
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155491
Log:
2009-12-28 H.J. Lu
Backport from mainline:
2009-1
--- Comment #13 from hjl dot tools at gmail dot com 2009-12-28 16:46
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #12 from hjl at gcc dot gnu dot org 2009-12-28 16:46 ---
Subject: Bug 41344
Author: hjl
Date: Mon Dec 28 16:46:11 2009
New Revision: 155489
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155489
Log:
Backport from mainline: Handle GIMPLE_COND in diagnose_sb_2.
gcc/
--- Comment #11 from hjl at gcc dot gnu dot org 2009-12-28 16:44 ---
Subject: Bug 41344
Author: hjl
Date: Mon Dec 28 16:44:34 2009
New Revision: 155488
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155488
Log:
Mention PR middle-end/41344.
Modified:
trunk/gcc/testsuite/Chan
--- Comment #10 from hjl at gcc dot gnu dot org 2009-12-28 16:41 ---
Subject: Bug 41344
Author: hjl
Date: Mon Dec 28 16:41:33 2009
New Revision: 155487
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155487
Log:
Handle GIMPLE_COND in diagnose_sb_2.
gcc/
2009-12-28 H.J. Lu
--- Comment #49 from steven at gcc dot gnu dot org 2009-12-28 15:40 ---
To make the test case work, I had to solve two errors by removing "static"
keywords:
ttest.cc:105: error: explicit template specialization cannot have a storage
class
ttest.cc:117: error: explicit template specializ
--- Comment #9 from janus at gcc dot gnu dot org 2009-12-28 15:24 ---
(In reply to comment #8)
> In the meantime I will test it for regressions.
Regtest finished successfully.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42353
Trunk bootstrap on powerpc64-linux (debian etch) fails on a warning
during libgomp build:
<<
if /bin/sh ./libtool --tag=CC --mode=compile
/home/guerby/build-144268/./gcc/xgcc -B/home/guerby/build-144268/./gcc/
-B/n/41/guerby/install-trunk-144268/powerpc64-unknown-linux-gnu/bin/
-B/n/41/guerby/inst
--- Comment #9 from hjl dot tools at gmail dot com 2009-12-28 14:59 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01156.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #8 from janus at gcc dot gnu dot org 2009-12-28 14:29 ---
Ok, here is a new patch, which fixes all problems reported here so far:
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 155486)
--- Comment #5 from amonakov at gcc dot gnu dot org 2009-12-28 14:23
---
(In reply to comment #4)
> Re. comment #3 - do you have an example of when/how this can happen? Perhaps
> you can add it to the comment.
>
Here, we are scheduling a loop that looks like this:
+---+
|
--- Comment #7 from janus at gcc dot gnu dot org 2009-12-28 14:15 ---
Here is a reduced version of the test case in comment #6:
module concrete_vector
type :: trivial_vector_type
end type
class(trivial_vector_type), pointer :: this
end module concrete_vector
module concrete_gradi
--- Comment #4 from steven at gcc dot gnu dot org 2009-12-28 12:34 ---
Re. comment #3 - do you have an example of when/how this can happen? Perhaps
you can add it to the comment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42245
--- Comment #10 from mikpe at it dot uu dot se 2009-12-28 12:11 ---
Matthias, your Debian patch includes the following, which is not part of the
trunk fix for PR40134 but instead appears to be a fragment from an early
version of the PR41175/PR40677 fix (which seems to depend on PR40134):
--- Comment #3 from abel at gcc dot gnu dot org 2009-12-28 12:06 ---
The patch mentioned by Alexander is not enough to fix the bug after applying
all other patches for sel-sched bugs. The actual problem is that when
redirecting an edge, the topological order of blocks in the currently
s
--- Comment #9 from paolo dot carlini at oracle dot com 2009-12-28 10:37
---
Good. To clarify, I have no personal objections to that specific kind of
backport to 4_4-branch... seems a bit late, but still, since the basic issue is
a wrong-code... up to the maintainers.
--
http://gcc
--- Comment #10 from paolo dot carlini at oracle dot com 2009-12-28 10:35
---
Ok. If you are stumbling again on exactly the same issue, please re-open,
otherwise file a new one... But hopefully everything will be fine ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35421
--- Comment #1 from debian-gcc at lists dot debian dot org 2009-12-28
09:43 ---
invalid, turned out to be a build error on my side.
Matthias
--
debian-gcc at lists dot debian dot org changed:
What|Removed |Added
--- Comment #8 from doko at ubuntu dot com 2009-12-28 09:40 ---
Created an attachment (id=19399)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19399&action=view)
pr40134 for 4.4
Mikael's analysis seems to be right; the __sync_synchronise backport requires
the backport of pr40134.
81 matches
Mail list logo
