http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48231
--- Comment #2 from Ralf Corsepius 2012-01-10
07:55:14 UTC ---
(In reply to comment #1)
> See if this helps:
You made my day - Your patch lets building gcc-4.6.2 for --target=h8300-rtems*
succeed (using binutils-2.22).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51796
--- Comment #8 from Jakub Jelinek 2012-01-10
07:47:55 UTC ---
Ah, obviously s/REG_UNUSED/REG_NORETURN/g in the patch, sorry for that.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51803
Janne Blomqvist changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51807
--- Comment #1 from lei 2012-01-10 07:10:13 UTC
---
(In reply to comment #0)
> 1.The project need to use libtool to compile la files.
> 2.Add LIBS+=" -lgcov" in configure
> 3.configure CFLAGS="-g -Wall -Werror -Wno-unknown-pragmas -fprofile-arcs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51796
Zdenek Sojka changed:
What|Removed |Added
CC||zsojka at seznam dot cz
--- Comment #7 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51807
Bug #: 51807
Summary: Fail to generate .gcno file when use libtool to
compile la library
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51483
--- Comment #5 from Geert Bosch 2012-01-10 02:55:46
UTC ---
If I understand correctly, you're changing the interface to pass the object
size (Esize) instead of the precision (RM_Size). That is not correct.
Right now, we have the assumption that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51806
Bug #: 51806
Summary: -flto ignores -Werror
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Compone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50105
--- Comment #12 from Jerry DeLisle 2012-01-10
00:40:55 UTC ---
Did any interpretation requests go in on this and did we get an answer back?
I am leaning toward current 4.7 is OK and 4.6 has the regression.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51483
--- Comment #4 from Andreas Schwab 2012-01-10 00:16:58
UTC ---
The front-end has never made that distinction for floating point types.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51804
--- Comment #5 from Benjamin Kosnik 2012-01-10
00:06:05 UTC ---
Ah! Ok. I didn't realize there was an -fabi-version=6. Now I get it. Stupid me,
for thinking v3 was the latest greatest, doh.
From:
http://gcc.gnu.org/onlinedocs/gcc-4.6.2/gcc/C_00
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51796
--- Comment #6 from Andreas Schwab 2012-01-09 23:52:41
UTC ---
Still fails in gcc_assert (n).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36485
--- Comment #3 from Andrew Pinski 2012-01-09
23:45:46 UTC ---
If you only want x86_64 then use a link from /usr/lib to /usr/lib64.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51483
--- Comment #3 from Eric Botcazou 2012-01-09
23:45:23 UTC ---
> Created attachment 26285 [details]
> Patch
I don't think it's correct. Like the middle-end, the Ada front-end has a
notion of precision (RM_Size) and a notion of size (Esize), so w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36485
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36485
Andrew Pinski changed:
What|Removed |Added
CC||booleandomain at gmail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40602
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673
--- Comment #10 from Benjamin Kosnik 2012-01-09
23:42:01 UTC ---
Thanks guys. This looks good, and is in trunk.
Pawel, thanks for noticing this. Please note that namespace versioning was
updated for 4.7.x to bring this experimental feature up
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673
--- Comment #9 from Benjamin Kosnik 2012-01-09
23:39:30 UTC ---
Author: bkoz
Date: Mon Jan 9 23:39:22 2012
New Revision: 183043
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183043
Log:
2012-01-09 Kai Tietz
PR libstc++/51673 par
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51800
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P4
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40677
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51787
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46328
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51796
--- Comment #5 from Jakub Jelinek 2012-01-09
23:24:16 UTC ---
Created attachment 26288
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26288
gcc47-pr51796.patch
Ah, REG_UNUSED might be still in next_note chain, not processed yet by
distribut
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46328
--- Comment #12 from Tobias Burnus 2012-01-09
23:23:29 UTC ---
Author: burnus
Date: Mon Jan 9 23:23:26 2012
New Revision: 183039
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183039
Log:
2012-01-09 Tobias Burnus
PR fortran/4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
--- Comment #43 from Chris Jefferson 2012-01-09
22:59:49 UTC ---
g++ only does this while compiling the C++ standard library. clang doesn't come
(by default) with a C++ standard library, so you have to use either libstdc++
(from g++) or libc++. W
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51805
Johannes Schaub changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
--- Comment #42 from joseph at codesourcery dot com 2012-01-09 22:51:04 UTC ---
The obvious issue with C++11 attributes (such as [[noreturn]]) is that the
syntactic bindings are (or were when I last looked at a draft)
incompatible with the synta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
--- Comment #41 from Ed Schouten 2012-01-09 22:48:35 UTC
---
(In reply to comment #40)
> There are several C++11 features which clang does not support, which g++ does.
> clang also defines __cplusplus == 201103L, despite not implementing large
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
--- Comment #40 from Chris Jefferson 2012-01-09
22:45:32 UTC ---
There are several C++11 features which clang does not support, which g++ does.
clang also defines __cplusplus == 201103L, despite not implementing large parts
of the C++11 standard.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51737
--- Comment #11 from Martin Jambor 2012-01-09
22:42:00 UTC ---
The problem is much more fundamental than just a clone removal while
also walking the clones of the same function although that is the
reason why we segfault. But that would be almos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
--- Comment #39 from Ed Schouten 2012-01-09 22:37:41 UTC
---
(In reply to comment #36)
> By your reasoning, FreeBSD really may as well take out code which requires
> __cplusplus == 201103L , as no compiler will support all of C++11 for several
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
--- Comment #38 from Steve Kargl
2012-01-09 22:31:03 UTC ---
On Mon, Jan 09, 2012 at 09:45:10PM +, chris at bubblescope dot net wrote:
>
> By your reasoning, FreeBSD really may as well take out code which
> requires __cplusplus == 201103L , a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51804
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #4 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40419
Meador Inge changed:
What|Removed |Added
CC||meadori at codesourcery dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
--- Comment #37 from bkorb at gnu dot org 2012-01-09 22:11:09 UTC ---
It is getting too confusing.
+/*
+ * 'g++ -std=c++11' defines __cplusplus to 201103L, which suggests
+ * that it conforms to ISO/IEC 14882:2011. Until G++ fully conforms,
+ * i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49642
--- Comment #7 from William J. Schmidt 2012-01-09
21:57:57 UTC ---
I should note that the problem still persists in 4.7 when -fno-tree-fre is
specified.
For 4.6, I am working on a solution along the lines Richi outlined above. We
may want to co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
--- Comment #36 from Chris Jefferson 2012-01-09
21:45:10 UTC ---
By your reasoning, FreeBSD really may as well take out code which requires
__cplusplus == 201103L , as no compiler will support all of C++11 for several
years I am sure. I would be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51804
--- Comment #3 from Benjamin Kosnik 2012-01-09
21:45:51 UTC ---
Created attachment 26287
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26287
pre-processed test file, run with -Wabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50077
--- Comment #1 from Dominique d'Humieres 2012-01-09
21:45:19 UTC ---
I have tested the -mcmodel=large option on some simple C tests and I got the
same kind of failures.
So -mcmodel=large seems broken on x86_64-apple-darwin10 (gcc 4.4.6, 4.5.3, a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51804
--- Comment #2 from Benjamin Kosnik 2012-01-09
21:44:39 UTC ---
Created attachment 26286
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26286
enables -Wabi for 'make check-libstdc++-v3'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51483
--- Comment #2 from Andreas Schwab 2012-01-09 21:35:02
UTC ---
Created attachment 26285
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26285
Patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
--- Comment #35 from Steve Kargl
2012-01-09 21:33:23 UTC ---
On Mon, Jan 09, 2012 at 08:32:00PM +, andreast at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
>
> --- Comment #34 from Andreas Tobler 2012-01-09
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51805
Bug #: 51805
Summary: Invalid list-initialization accepted
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51804
--- Comment #1 from Benjamin Kosnik 2012-01-09
21:27:35 UTC ---
Created attachment 26284
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26284
log file of 'make check-libstdc++-v3' with -Wabi
72 new fails
/20_util/tuple/cons/constexpr-2.cc
and others (full log attached as 20120109-libstdc++.sum.bz2)
I see a lot of things like:
s.h:752:7: warning: the mangled name of ‘void
__gnu_test::constexpr_single_value_constructible::_Concept<_Ttesttype,
_Tvaluetype, true>::__constraint() [with _Ttesttype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50023
--- Comment #4 from Dominique d'Humieres 2012-01-09
21:11:35 UTC ---
> To me it seems it was committed 10.10.2011. Here the relevant commit:
> http://gcc.gnu.org/viewcvs?view=revision&revision=179762
>
> Does this commit not show up for you?
Obv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51803
Bug #: 51803
Summary: gfortran getcwd at startup
Classification: Unclassified
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51796
--- Comment #4 from Mikael Pettersson 2012-01-09
20:56:12 UTC ---
The "|| find_reg_note (i3, REG_NORETURN, NULL)" bit also failed because i3 has
no notes at all. INSN_CODE (i3) == 437, which seems to correspond to "*call"
from m68k.md.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51802
Bug #: 51802
Summary: Duplicate mangling for OOP symbols
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
--- Comment #34 from Andreas Tobler 2012-01-09
20:32:00 UTC ---
Just to double check, shall I leave the backslash in this line?
c_fix_arg = "__attribute__\(\(__noreturn__\)\)";
And more important, do we have an ok for a commit of this patch?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51782
--- Comment #8 from Georg-Johann Lay 2012-01-09
20:30:35 UTC ---
It's scalar replacement of aggregates:
With -O1 code is wrong.
With -O1 -fno-tree-sra code is correct.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51792
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51791
Paul Thomas changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51792
--- Comment #2 from Paul Thomas 2012-01-09 20:26:14
UTC ---
Author: pault
Date: Mon Jan 9 20:25:55 2012
New Revision: 183032
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183032
Log:
2012-01-09 Paul Thomas
PR fortran/51791
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51791
--- Comment #2 from Paul Thomas 2012-01-09 20:26:05
UTC ---
Author: pault
Date: Mon Jan 9 20:25:55 2012
New Revision: 183032
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183032
Log:
2012-01-09 Paul Thomas
PR fortran/51791
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
--- Comment #33 from Steve Kargl
2012-01-09 20:13:08 UTC ---
On Fri, Jan 06, 2012 at 04:14:08PM +, bkorb at gnu dot org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
>
> --- Comment #32 from bkorb at gnu dot org 2012-01-06 16:14
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45644
Martin Jambor changed:
What|Removed |Added
CC||nobled at dreamwidth dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51759
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51759
--- Comment #8 from Martin Jambor 2012-01-09
20:03:15 UTC ---
Author: jamborm
Date: Mon Jan 9 20:03:08 2012
New Revision: 183031
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183031
Log:
2012-01-09 Martin Jambor
PR tree-opti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51197
--- Comment #8 from Tobias Burnus 2012-01-09
19:53:32 UTC ---
Author: burnus
Date: Mon Jan 9 19:53:27 2012
New Revision: 183030
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183030
Log:
2012-01-09 Harald Anlauf
Tobias Bur
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51197
Tobias Burnus changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51759
--- Comment #7 from Martin Jambor 2012-01-09
19:52:13 UTC ---
Author: jamborm
Date: Mon Jan 9 19:52:06 2012
New Revision: 183029
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183029
Log:
2012-01-09 Martin Jambor
PR tree-opti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50023
Tobias Grosser changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51758
--- Comment #7 from Mikael Morin 2012-01-09
19:01:44 UTC ---
Author: mikael
Date: Mon Jan 9 19:01:34 2012
New Revision: 183024
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183024
Log:
2012-01-09 Mikael Morin
PR fortran/51758
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51252
--- Comment #11 from dave.anglin at bell dot net 2012-01-09 18:44:24 UTC ---
On 1/9/2012 10:55 AM, patrick.marlier at gmail dot com wrote:
> Do all libitm tests passed on PA?
All tm tests pass on PA (well, there is one that fails on 32-bit HP-UX
d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51801
Bug #: 51801
Summary: [4.7 Regression] ICE in inline_small_functions
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45644
--- Comment #10 from Martin Jambor 2012-01-09
18:40:17 UTC ---
Author: jamborm
Date: Mon Jan 9 18:40:09 2012
New Revision: 183023
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183023
Log:
2012-01-09 Martin Jambor
PR tree-optimiz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51801
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51633
Dodji Seketeli changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51759
--- Comment #6 from Martin Jambor 2012-01-09
18:40:16 UTC ---
Author: jamborm
Date: Mon Jan 9 18:40:09 2012
New Revision: 183023
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183023
Log:
2012-01-09 Martin Jambor
PR tree-optimiza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51800
Tobias Burnus changed:
What|Removed |Added
Keywords||rejects-valid
CC|
4 x86_64 GNU/Linux
> rpm -qa "glibc*" | grep -e 'glibc-[0-9]' | sort -u
glibc-2.12-1.47.el6.i686
glibc-2.12-1.47.el6.x86_64
> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/app2/gcc/4.7.0-20120109-svn183001/i686/libexec/gcc/i686-unknown-linux-gnu/4.7.0/lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48231
DJ Delorie changed:
What|Removed |Added
CC||dj at redhat dot com
--- Comment #1 from DJ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51775
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51779
--- Comment #10 from Jack Howarth 2012-01-09
17:45:42 UTC ---
(In reply to comment #9)
> Thanks, Tobias. I did try out the gfortran 4.6.2 from here, and it does
> compile
> runnable code. Unfortunately, it still does not work with any version of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51787
--- Comment #3 from Douglas Mencken 2012-01-09
17:43:20 UTC ---
I can re-confirm that snapshots 4.7-20111231, 4.7-20120107 do fail (can't enter
this into "Known to fail" field, because despite that
http://gcc.gnu.org/bugzilla/page.cgi?id=fields.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51799
Bug #: 51799
Summary: Compiler ICE in vect_is_simple_use_1
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51779
--- Comment #9 from Tim Williams 2012-01-09 17:15:06 UTC
---
(In reply to comment #4)
> I forgot to mention that there exist also unofficial binaries for MacOS at:
> http://gcc.gnu.org/wiki/GFortranBinaries#MacOS
> Thus, that could be an altern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51798
--- Comment #3 from David Edelsohn 2012-01-09 17:11:32
UTC ---
Another alternative is to modify __gnu_cxx::_atomic_add() to perform acquire
semantics for positive increments and release semantics for negative
increments. That avoid creating a ne
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
--- Comment #62 from Ramana Radhakrishnan
2012-01-09 16:55:24 UTC ---
Author: ramana
Date: Mon Jan 9 16:55:16 2012
New Revision: 183019
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183019
Log:
2012-01-09 Ramana Radhakrishnan
B
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51124
--- Comment #14 from Patrick Marlier
2012-01-09 16:52:47 UTC ---
>From http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
regparm (number)
... Functions that take a variable number of arguments will continue to be
passed all of their argu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51796
--- Comment #3 from Jakub Jelinek 2012-01-09
16:52:57 UTC ---
I guess the assert should be adjusted, from gcc_assert (old_size != args_size);
to gcc_assert (old_size != args_size || find_reg_note (i3, REG_NORETURN,
NULL));
because we add the REG_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766
--- Comment #3 from David Edelsohn 2012-01-09 16:49:10
UTC ---
> It says above them "In most cases, these
> builtins are considered a full barrier." and only __sync_lock_test_and_set and
> __sync_lock_release specify different barrier semantics.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51252
Patrick Marlier changed:
What|Removed |Added
CC||patrick.marlier at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48075
Patrick Marlier changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766
--- Comment #2 from Jonathan Wakely 2012-01-09
15:45:06 UTC ---
(In reply to comment #1)
> The docs of __sync_* say
>
> This builtin is not a full barrier, but rather an @dfn{acquire barrier}.
> This means that references after the builtin canno
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51798
Richard Guenther changed:
What|Removed |Added
Priority|P3 |P1
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766
Richard Guenther changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #1 from Richard Guenthe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50913
Richard Guenther changed:
What|Removed |Added
Status|NEW |ASSIGNED
Component|middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50561
Richard Guenther changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51791
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51124
--- Comment #13 from Patrick Marlier
2012-01-09 15:22:45 UTC ---
As posted here http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01804.html, GCC
explicitly change the calling convention to stdcall when variable arguments in
x86/32 bits mode. So I am
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50199
--- Comment #12 from Jan Hubicka 2012-01-09 15:19:30
UTC ---
-flto-partition=none is a workaround for 4.7 compiler.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51680
--- Comment #17 from Jan Hubicka 2012-01-09 15:18:43
UTC ---
> This should not be fixed in the early inliner at all.
Well, it is not (just to summarize the disucssion on ML). The change is into
IPA inliner.
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50913
--- Comment #8 from Richard Guenther 2012-01-09
15:14:30 UTC ---
There is a disconnect on how we analyze data-references during SCOP detection
(outermost_loop is the root of the loop tree) and during SESE-to-poly where
outermost is determined by
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51124
torvald at gcc dot gnu.org changed:
What|Removed |Added
CC||rth at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50561
--- Comment #4 from Richard Guenther 2012-01-09
14:41:04 UTC ---
Re-confirmed. Reduced testcase:
void f (unsigned *s)
{
int n;
for (n = 0; n < 256; n++)
s[n] = 0;
}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51798
--- Comment #1 from David Edelsohn 2012-01-09 14:37:35
UTC ---
Proposed patch:
http://gcc.gnu.org/ml/libstdc++/2012-01/msg00044.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51798
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
1 - 100 of 151 matches
Mail list logo
