On 18/02/14 00:12, DJ Delorie wrote:
I presume these will be part of the headers for the library
distributed for msp430 gcc by TI/Redhat?
I can't speak for TI's or Red Hat's plans. GNU's typical non-custom
embedded runtime is newlib/libgloss, which usually doesn't have that
much in the way
On Mon, 17 Feb 2014, Jan Hubicka wrote:
Yeah, ok. But we treat those types (B and C) TBAA equivalent because
structurally they are the same ;) Luckily C has a proper field
for its base (proper means that offset and size are correct as well
as the type). It indeed has DECL_ARTIFICIAL
On Tue, 18 Feb 2014, Richard Biener wrote:
On Mon, 17 Feb 2014, Jan Hubicka wrote:
Yeah, ok. But we treat those types (B and C) TBAA equivalent because
structurally they are the same ;) Luckily C has a proper field
for its base (proper means that offset and size are correct as
Several of you have said that the standard and compiler should not
permit speculative writes of atomics, or (effectively) that the
compiler should preserve dependencies. In simple examples it's easy
to see what that means, but in general it's not so clear what the
language should guarantee,
On Tue, Feb 18, 2014 at 12:12:06PM +, Peter Sewell wrote:
Several of you have said that the standard and compiler should not
permit speculative writes of atomics, or (effectively) that the
compiler should preserve dependencies.
The example below only deals with control dependencies; so
Hi everyone,
I am developing on a custom design using the LatticeMico32
architecture and I use gcc 4.5.1 to compile C code for this arch.
In this architecture, the loading of an address 0x always
takes two assembly instructions to fetch the address because
immediates are on 16 bits :
On Tue, Feb 18, 2014 at 12:12:06PM +, Peter Sewell wrote:
Several of you have said that the standard and compiler should not
permit speculative writes of atomics, or (effectively) that the
compiler should preserve dependencies. In simple examples it's easy
to see what that means, but in
Hi Paul,
Thanks for the document. I'm looking forward to reading the bits about
dependency chains in Linux.
One point of confusion for me... Example 4 says language must allow.
Shouldn't that be language is permitted to allow?
When we say allow, we mean that the optimised execution should be
On Mon, 2014-02-17 at 16:05 -0800, Linus Torvalds wrote:
And exactly because I know enough, I would *really* like atomics to be
well-defined, and have very clear - and *local* - rules about how they
can be combined and optimized.
Local?
None of this if you can prove that the read has value X
Hi Paul,
On 18 February 2014 14:56, Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
On Tue, Feb 18, 2014 at 12:12:06PM +, Peter Sewell wrote:
Several of you have said that the standard and compiler should not
permit speculative writes of atomics, or (effectively) that the
compiler
On Mon, 2014-02-17 at 16:18 -0800, Linus Torvalds wrote:
On Mon, Feb 17, 2014 at 3:41 PM, Torvald Riegel trie...@redhat.com wrote:
There's an underlying problem here that's independent from the actual
instance that you're worried about here: no sense is a ultimately a
matter of
On Mon, 2014-02-17 at 19:00 -0800, Paul E. McKenney wrote:
On Mon, Feb 17, 2014 at 12:18:21PM -0800, Linus Torvalds wrote:
On Mon, Feb 17, 2014 at 11:55 AM, Torvald Riegel trie...@redhat.com wrote:
Which example do you have in mind here? Haven't we resolved all the
debated examples,
The DWARF Debugging Information Format Committee (http://dwarfstd.org)
is nearing completion on the DWARF Version 5 standard. We anticipate
a public comment draft to be released mid-2014. As in the past, we
have attempted where possible to make DWARF Version 5 backward compatible
with previous
On 18 February 2014 12:53, Peter Zijlstra pet...@infradead.org wrote:
On Tue, Feb 18, 2014 at 12:12:06PM +, Peter Sewell wrote:
Several of you have said that the standard and compiler should not
permit speculative writes of atomics, or (effectively) that the
compiler should preserve
On Mon, 2014-02-17 at 19:42 -0800, Linus Torvalds wrote:
On Mon, Feb 17, 2014 at 7:24 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
As far as I can tell, the intent is that you can't do value
speculation (except perhaps for the relaxed, which quite frankly
sounds largely
On Mon, 2014-02-17 at 16:09 -0800, Linus Torvalds wrote:
On Mon, Feb 17, 2014 at 3:17 PM, Torvald Riegel trie...@redhat.com wrote:
On Mon, 2014-02-17 at 14:32 -0800,
Stop claiming it can return 1.. It *never* returns 1 unless you do
the load and *verify* it, or unless the load itself can
On Tue, Feb 18, 2014 at 03:33:35PM +, Peter Sewell wrote:
Hi Paul,
On 18 February 2014 14:56, Paul E. McKenney paul...@linux.vnet.ibm.com
wrote:
On Tue, Feb 18, 2014 at 12:12:06PM +, Peter Sewell wrote:
Several of you have said that the standard and compiler should not
permit
On Tue, Feb 18, 2014 at 7:31 AM, Torvald Riegel trie...@redhat.com wrote:
On Mon, 2014-02-17 at 16:05 -0800, Linus Torvalds wrote:
And exactly because I know enough, I would *really* like atomics to be
well-defined, and have very clear - and *local* - rules about how they
can be combined and
On Tue, Feb 18, 2014 at 04:56:40PM +0100, Torvald Riegel wrote:
On Mon, 2014-02-17 at 19:00 -0800, Paul E. McKenney wrote:
On Mon, Feb 17, 2014 at 12:18:21PM -0800, Linus Torvalds wrote:
On Mon, Feb 17, 2014 at 11:55 AM, Torvald Riegel trie...@redhat.com
wrote:
Which example do
On Tue, Feb 18, 2014 at 04:38:40PM +0100, Torvald Riegel wrote:
On Mon, 2014-02-17 at 16:18 -0800, Linus Torvalds wrote:
On Mon, Feb 17, 2014 at 3:41 PM, Torvald Riegel trie...@redhat.com wrote:
There's an underlying problem here that's independent from the actual
instance that you're
On Tue, Feb 18, 2014 at 08:49:13AM -0800, Linus Torvalds wrote:
On Tue, Feb 18, 2014 at 7:31 AM, Torvald Riegel trie...@redhat.com wrote:
On Mon, 2014-02-17 at 16:05 -0800, Linus Torvalds wrote:
And exactly because I know enough, I would *really* like atomics to be
well-defined, and have
On Tue, Feb 18, 2014 at 03:16:33PM +, Mark Batty wrote:
Hi Paul,
Thanks for the document. I'm looking forward to reading the bits about
dependency chains in Linux.
And I am looking forward to your thoughts on those bits!
One point of confusion for me... Example 4 says language must
On Tue, Feb 18, 2014 at 4:12 AM, Peter Sewell peter.sew...@cl.cam.ac.uk wrote:
For example, suppose we have, in one compilation unit:
void f(int ra, int*rb) {
if (ra==42)
*rb=42;
else
*rb=42;
}
So this is a great example, and in general I really like
On Tue, Feb 18, 2014 at 8:17 AM, Torvald Riegel trie...@redhat.com wrote:
Consume operation: no reads in the current thread dependent on the
value currently loaded can be reordered before this load
I can't remember seeing that language in the standard (ie, C or C++).
Where is this from?
On 18 February 2014 17:38, Linus Torvalds torva...@linux-foundation.org wrote:
On Tue, Feb 18, 2014 at 4:12 AM, Peter Sewell peter.sew...@cl.cam.ac.uk
wrote:
For example, suppose we have, in one compilation unit:
void f(int ra, int*rb) {
if (ra==42)
*rb=42;
else
On 18 February 2014 17:16, Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
On Tue, Feb 18, 2014 at 08:49:13AM -0800, Linus Torvalds wrote:
On Tue, Feb 18, 2014 at 7:31 AM, Torvald Riegel trie...@redhat.com wrote:
On Mon, 2014-02-17 at 16:05 -0800, Linus Torvalds wrote:
And exactly because
On Tue, Feb 18, 2014 at 10:21 AM, Peter Sewell
peter.sew...@cl.cam.ac.uk wrote:
This is a bit more subtle, because (on ARM and POWER) removing the
dependency and conditional branch is actually in general *not* equivalent
in the hardware, in a concurrent context.
So I agree, but I think that's
On Tue, Feb 18, 2014 at 10:23 AM, Peter Sewell
peter.sew...@cl.cam.ac.uk wrote:
interesting list. So are you saying that value-range-analysis and
such-like (I say glibly, without really knowing what such-like
refers to here) are fundamentally incompatible with
the kernel code
No, it's fine
Non-ODR types born from other frontends will then need to be made to
alias all the ODR variants that can be done by storing them into the
current canonical type hash.
(I wonder if we want to support cross language aliasing for non-POD?)
Surely for accessing components of non-POD
On Tue, Feb 18, 2014 at 09:44:48AM -0800, Linus Torvalds wrote:
On Tue, Feb 18, 2014 at 8:17 AM, Torvald Riegel trie...@redhat.com wrote:
[ . . . ]
The standard is clear on what's required. I strongly suggest reading
the formalization of the memory model by Batty et al.
Can you point to
On Tue, Feb 18, 2014 at 06:23:47PM +, Peter Sewell wrote:
On 18 February 2014 17:16, Paul E. McKenney paul...@linux.vnet.ibm.com
wrote:
On Tue, Feb 18, 2014 at 08:49:13AM -0800, Linus Torvalds wrote:
On Tue, Feb 18, 2014 at 7:31 AM, Torvald Riegel trie...@redhat.com wrote:
On Mon,
On Tue, Feb 18, 2014 at 10:49:27AM -0800, Linus Torvalds wrote:
On Tue, Feb 18, 2014 at 10:21 AM, Peter Sewell
peter.sew...@cl.cam.ac.uk wrote:
This is a bit more subtle, because (on ARM and POWER) removing the
dependency and conditional branch is actually in general *not* equivalent
in
On Tue, 2014-02-18 at 09:44 -0800, Linus Torvalds wrote:
On Tue, Feb 18, 2014 at 8:17 AM, Torvald Riegel trie...@redhat.com wrote:
The standard is clear on what's required. I strongly suggest reading
the formalization of the memory model by Batty et al.
Can you point to it? Because I can
On Tue, 2014-02-18 at 08:55 -0800, Paul E. McKenney wrote:
On Tue, Feb 18, 2014 at 04:38:40PM +0100, Torvald Riegel wrote:
On Mon, 2014-02-17 at 16:18 -0800, Linus Torvalds wrote:
On Mon, Feb 17, 2014 at 3:41 PM, Torvald Riegel trie...@redhat.com
wrote:
There's an underlying
On Tue, 2014-02-18 at 12:12 +, Peter Sewell wrote:
Several of you have said that the standard and compiler should not
permit speculative writes of atomics, or (effectively) that the
compiler should preserve dependencies. In simple examples it's easy
to see what that means, but in general
On Tue, 2014-02-18 at 18:21 +, Peter Sewell wrote:
On 18 February 2014 17:38, Linus Torvalds torva...@linux-foundation.org
wrote:
On Tue, Feb 18, 2014 at 4:12 AM, Peter Sewell peter.sew...@cl.cam.ac.uk
wrote:
For example, suppose we have, in one compilation unit:
void f(int
On Tue, 2014-02-18 at 08:49 -0800, Linus Torvalds wrote:
On Tue, Feb 18, 2014 at 7:31 AM, Torvald Riegel trie...@redhat.com wrote:
On Mon, 2014-02-17 at 16:05 -0800, Linus Torvalds wrote:
And exactly because I know enough, I would *really* like atomics to be
well-defined, and have very
On Tue, Feb 18, 2014 at 09:43:31PM +0100, Torvald Riegel wrote:
xagsmtp5.20140218204423.3...@bldgate.vnet.ibm.com
X-Xagent-Gateway: bldgate.vnet.ibm.com (XAGSMTP5 at BLDGATE)
On Tue, 2014-02-18 at 12:12 +, Peter Sewell wrote:
Several of you have said that the standard and compiler
On Tue, 2014-02-18 at 09:16 -0800, Paul E. McKenney wrote:
On Tue, Feb 18, 2014 at 08:49:13AM -0800, Linus Torvalds wrote:
On Tue, Feb 18, 2014 at 7:31 AM, Torvald Riegel trie...@redhat.com wrote:
On Mon, 2014-02-17 at 16:05 -0800, Linus Torvalds wrote:
And exactly because I know enough,
On Tue, Feb 18, 2014 at 10:21:56PM +0100, Torvald Riegel wrote:
Yes, I do. But that seems to be volatile territory. It crosses the
boundaries of the abstract machine, and thus is input/output. Which
fraction of your atomic accesses can read values produced by hardware?
I would still suppose
On Tue, 2014-02-18 at 22:40 +0100, Peter Zijlstra wrote:
On Tue, Feb 18, 2014 at 10:21:56PM +0100, Torvald Riegel wrote:
Well, that's how atomics that aren't volatile are defined in the
standard. I can see that you want something else too, but that doesn't
mean that the other thing is
4. Some drivers allow user-mode code to mmap() some of their
state. Any changes undertaken by the user-mode code would
be invisible to the compiler.
A good point, but a compiler that doesn't try to (incorrectly) assume
something about the semantics of mmap will simply see that
On Tue, Feb 18, 2014 at 1:21 PM, Torvald Riegel trie...@redhat.com wrote:
So imagine that you have some clever global optimizer that sees that
the program never ever actually sets the dirty bit at all in any
thread, and then uses that kind of non-local knowledge to make
optimization
On Tue, Feb 18, 2014 at 10:40:15PM +0100, Torvald Riegel wrote:
xagsmtp4.20140218214207.8...@vmsdvm9.vnet.ibm.com
X-Xagent-Gateway: vmsdvm9.vnet.ibm.com (XAGSMTP4 at VMSDVM9)
On Tue, 2014-02-18 at 09:16 -0800, Paul E. McKenney wrote:
On Tue, Feb 18, 2014 at 08:49:13AM -0800, Linus Torvalds
On 18 February 2014 20:43, Torvald Riegel trie...@redhat.com wrote:
On Tue, 2014-02-18 at 12:12 +, Peter Sewell wrote:
Several of you have said that the standard and compiler should not
permit speculative writes of atomics, or (effectively) that the
compiler should preserve dependencies.
Hello.
I am sending this at the behest of Renato. I have been working on the ARM
integrated assembler in LLVM and came across an interesting item in the Linux
kernel.
I am wondering if this is an unstated covenant between the kernel and GCC or
simply a clever use of an unintended/undefined
On Tue, Feb 18, 2014 at 6:56 PM, Saleem Abdulrasool
compn...@compnerd.org wrote:
Hello.
I am sending this at the behest of Renato. I have been working on the ARM
integrated assembler in LLVM and came across an interesting item in the Linux
kernel.
I am wondering if this is an unstated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60258
Bug ID: 60258
Summary: Member initialization for atomic fail.
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60040
--- Comment #3 from Sebastian Huber sebastian.hu...@embedded-brains.de ---
With avr-rtems4.11-gcc (GCC) 4.9.0 20140218 (experimental) I still get the
error:
avr-rtems4.11-gcc -fpreprocessed -w -mmcu=atmega128 -O2 -s test.i -o /dev/null
test.i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60233
--- Comment #12 from Steven Noonan steven at uplinklabs dot net ---
Thanks for the fast resolution, Jakub!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555
--- Comment #23 from David Binderman dcb314 at hotmail dot com ---
(In reply to Jakub Jelinek from comment #22)
So, shall we just apply #c15 here?
Diff works fine for me for over five weeks now, so I say yes.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60258
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60255
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60190
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
CC||abutcher at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60064
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60190
--- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org ---
Actually, that was for PR60064. This one started with r202539, the disappeared
with revert in r202570, then started ICEing again with r202611.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60254
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60252
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60253
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60251
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60250
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60248
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60243
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||hubicka at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60198
Sylwester Arabas slayoo at staszic dot waw.pl changed:
What|Removed |Added
CC||slayoo at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60174
--- Comment #12 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #11)
Reproducible on x86{-64}/Linux with the following procedure:
- copy $srcdir/gcc/testsuite/ada/acats/support/repbody.ada to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60174
--- Comment #13 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
you can also build a cross-gcc/gnat for this spec.
all you need for it, are the system root files, but I can give them to you.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60248
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60040
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183
Bug 56183 depends on bug 60040, which changed state.
Bug 60040 Summary: AVR: error: unable to find a register to spill in class
'POINTER_REGS'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60040
What|Removed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60260
Bug ID: 60260
Summary: MIPS sign extension issue
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60221
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60174
--- Comment #14 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
Unfortunately that's always telling me
error: gnat1drv.adb must be recompiled (system.ads has been modified)
error: s-stalib.adb must be recompiled (system.ads has been
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60040
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
Known to fail||4.8.3, 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128
--- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr ---
The following patch fixes the issues reported in comment 6
--- ../_clean/libgfortran/io/write_float.def2014-01-21 08:30:57.0
+0100
+++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60174
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60205
--- Comment #1 from Uroš Bizjak ubizjak at gmail dot com ---
Created attachment 32158
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32158action=edit
Proposed patch
Patch that implements AVX512F warnings.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60205
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60261
Bug ID: 60261
Summary: [4.9 Regression] Weird java install with
--enable-version-specific-runtime-libs
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60261
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58844
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60258
--- Comment #2 from ja.gcc.bugzilla at aptsketch dot com ---
auto foo() - void
vs
void foo()
is more of just a stylistic issue. There is nothing wrong with both. To me both
are good.
The bug is about std::atomic member initialization. Where if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60258
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
Sure, my comment was about this stylistic issue, not about the real bug (if
any, haven't tried it). Note your testcase isn't self-contained, you probably
need #include atomic.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60261
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
In particular
dbexecdir='$(toolexeclibdir)/'$multi_os_directory/$gcjsubdir
doesn't seem to work as $multi_os_directory contains a '..'. I get:
toolexecdir =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60261
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
libjavamath uses
nativeexeclib_LTLIBRARIES = libjavamath.la
and inside classpath
nativeexeclibdir='${toolexeclibdir}/gcj-'`cat
${srcdir}/../../gcc/BASE-VER`-`awk -F:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60262
Bug ID: 60262
Summary: explicit destructor call to destructor of Base
accepted without using a qualified-id
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60230
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60261
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
Hmm, it seems to me that
# Determine where the standard .db file and GNU Classpath JNI
# libraries are found.
gcjsubdir=gcj-$gcjversion-$libgcj_soversion
multi_os_directory=`$CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60174
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Attachment #32122|0 |1
is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60223
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
CC||mpolacek at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60243
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
Oh, and ipa_profile_generate_summary is dominated by symtab_get_node ()
hashtable lookup ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60188
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60243
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Richard Biener from comment #4)
Oh, and ipa_profile_generate_summary is dominated by symtab_get_node ()
hashtable lookup ...
here:
int
estimate_num_insns (gimple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60188
--- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org ---
But with -std=c++0x the ICE started earlier, even r145119 ICEs.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59758
--- Comment #2 from Jose E. Marchesi jose.marchesi at oracle dot com ---
I can reproduce this problem in sparc64-*-linux-gnu. Looks like there
are many missing definitions for stub structs in
sanitizer_platform_limits_posix.h for sparc. Working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60243
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org ---
Created attachment 32162
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32162action=edit
patch 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60243
--- Comment #7 from Richard Biener rguenth at gcc dot gnu.org ---
Created attachment 32163
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32163action=edit
patch 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60193
--- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org ---
Author: ktietz
Date: Tue Feb 18 12:49:15 2014
New Revision: 207844
URL: http://gcc.gnu.org/viewcvs?rev=207844root=gccview=rev
Log:
2014-02-18 Kai Tietz kti...@redhat.com
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60261
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Richard Biener from comment #4)
Hmm, it seems to me that
# Determine where the standard .db file and GNU Classpath JNI
# libraries are found.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60193
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60261
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org ---
Trying
Index: libjava/Makefile.am
===
--- libjava/Makefile.am (revision 207837)
+++ libjava/Makefile.am (working
1 - 100 of 284 matches
Mail list logo
