Marek,
Your response is MOST helpful. THANK YOU!
Regards,
George...
- Original Message -
From: Marek Polacek pola...@redhat.com
To: George R Goffe grgo...@yahoo.com
Cc: gcc@gcc.gnu.org gcc@gcc.gnu.org
Sent: Monday, August 5, 2013 10:16 PM
Subject: Re: c++/linker problems maybe?
On
On Mon, 2013-08-05 at 11:49 -0700, Linus Torvalds wrote:
Ugh. Why the crazy update_jump_label script stuff?
After playing with the patches again, I now understand why I did that.
It wasn't just for optimization.
Currently the way jump labels work is that we use asm goto() and place a
5 byte
Hi all,
I am form RTEMS org, recently we are working on atomic support for RTEMS. The
C11 stdatomic.h has been ported to RTEMS. But when i build the atomic test case
for pc686 BSP it will post some error like this :
On 6 August 2013 15:47, Deng Hengyi wrote:
And i have found some mail list talking about gcc has remove lock free atomic
int support [1][2], is this true? or just some error caused by my toolchain?
I am waiting for your reply, Thank you!
[1].
Hi Jonathan,
Thank you for your reply.
And about the error i encounter, do you have any advice? maybe it is caused by
my toolchain not install rightly?
In the standard pc686 architecture(not cross compile on RTEMS) will it
encounter the similar error?
WeiY
Best Regards
在
On Mon, 2013-08-05 at 15:03 +0100, Richard Sandiford wrote:
Sorry for the long mail and for what's probably an FAQ. I did try to find
an answer without bothering the list... (and showing my ignorance so much :-))
At the moment, the s390 backend treats all atomic loads as simple loads
and
On 6 August 2013 16:30, Deng Hengyi wrote:
Hi Jonathan,
Thank you for your reply.
And about the error i encounter, do you have any advice? maybe it is caused
by my toolchain not install rightly?
In the standard pc686 architecture(not cross compile on RTEMS) will it
encounter the similar
On Mon, 2013-08-05 at 14:43 -0700, H. Peter Anvin wrote:
For unconditional jmp that should be pretty safe barring any fundamental
changes to the instruction set, in which case we can enable it as
needed, but for extra robustness it probably should skip prefix bytes.
Would the assembler add
On 08/06/2013 09:15 AM, Steven Rostedt wrote:
On Mon, 2013-08-05 at 14:43 -0700, H. Peter Anvin wrote:
For unconditional jmp that should be pretty safe barring any fundamental
changes to the instruction set, in which case we can enable it as
needed, but for extra robustness it probably
On Tue, 2013-08-06 at 09:19 -0700, H. Peter Anvin wrote:
On 08/06/2013 09:15 AM, Steven Rostedt wrote:
On Mon, 2013-08-05 at 14:43 -0700, H. Peter Anvin wrote:
For unconditional jmp that should be pretty safe barring any fundamental
changes to the instruction set, in which case we can
On 08/06/2013 09:26 AM, Steven Rostedt wrote:
No, but if we ever end up doing MPX in the kernel, for example, we would
have to put an MPX prefix on the jmp.
Well then we just have to update the rest of the jump label code :-)
For MPX in the kernel, this would be a small part of the
On Tue, Aug 6, 2013 at 7:19 AM, Steven Rostedt rost...@goodmis.org wrote:
After playing with the patches again, I now understand why I did that.
It wasn't just for optimization.
[explanation snipped]
Anyway, if you feel that update_jump_label is too complex, I can go the
update at early
On Tue, 2013-08-06 at 10:48 -0700, Linus Torvalds wrote:
So I wonder if this is a ok, let's not bother, it's not worth the
pain issue. 128 bytes of offset is very small, so there probably
aren't all that many cases that would use it.
OK, I'll forward port the original patches for the hell of
Hi,
i386elf.h defines:
/* The ELF ABI for the i386 says that records and unions are returned
in memory. */
#define SUBTARGET_RETURN_IN_MEMORY(TYPE, FNTYPE) \
(TYPE_MODE (TYPE) == BLKmode \
|| (VECTOR_MODE_P (TYPE_MODE (TYPE)) int_size_in_bytes (TYPE) == 8))
and as such
On Tue, Aug 6, 2013 at 1:46 PM, Nathan Sidwell nat...@acm.org wrote:
Hi,
i386elf.h defines:
/* The ELF ABI for the i386 says that records and unions are returned
in memory. */
#define SUBTARGET_RETURN_IN_MEMORY(TYPE, FNTYPE) \
(TYPE_MODE (TYPE) == BLKmode \
||
* Steven Rostedt (rost...@goodmis.org) wrote:
On Tue, 2013-08-06 at 10:48 -0700, Linus Torvalds wrote:
So I wonder if this is a ok, let's not bother, it's not worth the
pain issue. 128 bytes of offset is very small, so there probably
aren't all that many cases that would use it.
OK,
Hi!
Since some time, I'm running compile tests for binutils/gdb/gcc on
three of my machines. As you noticed, they're hitting errors from time
to time.
So I decided to spend it a small web frontend:
http://toolchain.lug-owl.de/buildbot/
Maybe it's useful to somebody.
MfG, JBG
--
On Tue, 2013-08-06 at 16:33 -0400, Mathieu Desnoyers wrote:
Steve, perhaps you could add a mode to your binary rewriting program
that counts the number of 2-byte vs 5-byte jumps found, and if possible
get a breakdown of those per subsystem ?
I actually started doing that, as I was curious to
On 22 July 2013 21:39, Jason Merrill wrote:
I'd like to make some changes to the GCC git-svn mirror. Specifically, I
want to move all the SVN branches from remotes/ into heads/ and split the
subdirectory branches (redhat, google, etc) into the individual branches.
Should I leave the SVN
On 7 August 2013 00:56, Jonathan Wakely wrote:
On 22 July 2013 21:39, Jason Merrill wrote:
I'd like to make some changes to the GCC git-svn mirror. Specifically, I
want to move all the SVN branches from remotes/ into heads/ and split the
subdirectory branches (redhat, google, etc) into the
On Tue, 2013-08-06 at 16:43 -0400, Steven Rostedt wrote:
On Tue, 2013-08-06 at 16:33 -0400, Mathieu Desnoyers wrote:
Steve, perhaps you could add a mode to your binary rewriting program
that counts the number of 2-byte vs 5-byte jumps found, and if possible
get a breakdown of those per
On Tue, 2013-08-06 at 20:45 -0400, Steven Rostedt wrote:
[3.387362] short jumps: 106
[3.390277] long jumps: 330
Thus, approximately 25%. Not bad.
Also, where these happen to be is probably even more important than how
many. If all the short jumps happen in slow paths, it's rather
On Tue, Aug 06, 2013 at 08:56:00PM -0400, Steven Rostedt wrote:
On Tue, 2013-08-06 at 20:45 -0400, Steven Rostedt wrote:
[3.387362] short jumps: 106
[3.390277] long jumps: 330
Thus, approximately 25%. Not bad.
Also, where these happen to be is probably even more important
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58088
--- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org ---
Another testcases:
int
bar (int i)
{
return 1 | ((i * 2) 254);
}
int
foo (int i)
{
return 1 | ((i * 2) 255);
}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
--- Comment #13 from janus at gcc dot gnu.org ---
Author: janus
Date: Tue Aug 6 08:20:17 2013
New Revision: 201521
URL: http://gcc.gnu.org/viewcvs?rev=201521root=gccview=rev
Log:
2013-08-06 Janus Weil ja...@gcc.gnu.org
PR fortran/57306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58088
--- Comment #5 from ktkachov at gcc dot gnu.org ---
(In reply to Marek Polacek from comment #4)
Another testcases:
int
bar (int i)
{
return 1 | ((i * 2) 254);
}
int
foo (int i)
{
return 1 | ((i * 2) 255);
}
This happens for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207
--- Comment #13 from janus at gcc dot gnu.org ---
Test case from PR 57306 comment 7 (see also
http://gcc.gnu.org/ml/fortran/2013-07/msg00103.html):
type :: c
end type c
type(c), target :: x
class(c), pointer :: px = x
if (.not.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40523
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Resolution|WONTFIX |FIXED
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58088
--- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org ---
Well, for (i * 2) 128 the BIT_AND_EXPR case doesn't do anything, but then we
get into BIT_IOR_EXPR case, here the Canonicalize (X C1) | C2. code changes
that into (i * 2) 255,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213
--- Comment #15 from janus at gcc dot gnu.org ---
Another test case related to comment 12 (from
http://gcc.gnu.org/ml/fortran/2013-08/msg00015.html):
integer, target :: tgt
type t2
end type t2
type(t2), target :: tgt2
type t
class(*), pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57959
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213
--- Comment #16 from janus at gcc dot gnu.org ---
(In reply to janus from comment #15)
and also the patches from comment 8 and 10 don't help here.
... but the following does:
Index: gcc/fortran/expr.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58039
--- Comment #2 from Alexander Barkov bar at mariadb dot org ---
Any updates? Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213
--- Comment #17 from janus at gcc dot gnu.org ---
(In reply to janus from comment #16)
and also the patches from comment 8 and 10 don't help here.
... but the following does:
... without any testsuite failures, btw.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58091
--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com ---
However current ICC agrees with GCC. We may have something in Bugzilla.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
Martin Jambor jamborm at gcc dot gnu.org changed:
What|Removed |Added
URL|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58091
--- Comment #2 from fimbul77 at gmail dot com ---
3.4 Name lookup
The name lookup rules apply uniformly to all names (including typedef-names
(7.1.3), namespace-names (7.3), and class-names (9.1)) wherever the grammar
allows such names in the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58092
Bug ID: 58092
Summary: BEQ (Branch on equal) jumps to wrong address (executes
conditional code!)
Product: gcc
Version: 4.6.4
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58092
--- Comment #1 from Rafał Miłecki zajec5 at gmail dot com ---
Created attachment 30618
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30618action=edit
Compiled version of test.c
Command I use to compile test.c:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58091
--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com ---
Generally speaking, this is a basic C++ issue, doesn't have to do with the
recent constexpr, and normally icc is very solid about those. Remember there
are also DRs, besides the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58092
--- Comment #2 from Rafał Miłecki zajec5 at gmail dot com ---
### Decompiled object ###
test:
0: 24020002li v0,2
4: 24030004li v1,4
8: aca2sw v0,0(a1)
c: 10830002beq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58014
--- Comment #2 from John David Anglin danglin at gcc dot gnu.org ---
Introduced in r197845:
2013-04-12 Richard Biener rguent...@suse.de
* gimple.c (is_gimple_constant): Vector CONSTRUCTORs should
not be considered a gimple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58093
Bug ID: 58093
Summary: Semi-bogus warning about narrowing conversions and
variadic templates
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57987
Martin Jambor jamborm at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58092
--- Comment #3 from Mikael Pettersson mikpe at it dot uu.se ---
Please attach the pre-processed test.i (gcc -E or -save-temps).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58093
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58094
Bug ID: 58094
Summary: [4.9 Regression] IPA devirt testsuite errors
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58094
David Edelsohn dje at gcc dot gnu.org changed:
What|Removed |Added
Target||powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58094
--- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org ---
I am not able to reproduce those on gcc110.fsffrance.org. Would be possible to
have -fdump-ipa-all -fdump-tree-all dumps of the devirt testcase? I think both
are related to fast that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #30 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Hi Martin,
I have bootstrapped this patch for i686-pc-linux-gnu and have
seen some excess errors in your test script:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58092
--- Comment #4 from Rafał Miłecki zajec5 at gmail dot com ---
Created attachment 30619
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30619action=edit
test.i generated by adding -save-temps
Hi Mikael!
I added -save-temps at the end of my
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #31 from Martin Jambor jamborm at gcc dot gnu.org ---
(In reply to Bernd Edlinger from comment #30)
Hi Martin,
I have bootstrapped this patch for i686-pc-linux-gnu and have
seen some excess errors in your test script:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #32 from Martin Jambor jamborm at gcc dot gnu.org ---
Author: jamborm
Date: Tue Aug 6 15:08:59 2013
New Revision: 201530
URL: http://gcc.gnu.org/viewcvs?rev=201530root=gccview=rev
Log:
2013-08-06 Martin Jambor mjam...@suse.cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58093
--- Comment #2 from Nick Maclaren nmm1 at cam dot ac.uk ---
I have no idea why you think that it is a narrowing conversion. The
references I gave have been essentially unchanged since C90, and there
is required to be no loss of information. All
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #33 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Martin Jambor from comment #31)
I can't reproduce this with the -m32 flag on my x86_64... do
you still have the compiler built on an i686? If so, could you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58093
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Nick Maclaren from comment #2)
I have no idea why you think that it is a narrowing conversion.
Please read the definition of a narrowing conversion in C++11, at 8.5.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58093
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Nick Maclaren from comment #2)
All values of int can be
represented in unsigned long in any conforming implementation.
Except the negative ones!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58094
--- Comment #3 from David Edelsohn dje at gcc dot gnu.org ---
Created attachment 30620
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30620action=edit
ipa and tree dumps
-fdump-ipa-all -fdump-tree-all output file attached in gzipped tar file.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #34 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
by the way the initializer of struct s a =
seems to generate warnings at -Wall, because some brackets are missing:
changed that to
struct s a = {0,{{0,0},{0,0}}};
but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58095
Bug ID: 58095
Summary: SIMD code requiring auxiliary array for best
optimization
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #35 from Martin Jambor jamborm at gcc dot gnu.org ---
(In reply to Bernd Edlinger from comment #34)
by the way the initializer of struct s a =
seems to generate warnings at -Wall, because some brackets are missing:
changed that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #36 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Martin Jambor from comment #35)
(In reply to Bernd Edlinger from comment #34)
by the way the initializer
of struct s a =
seems to generate warnings at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58095
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC|siavashserver at gmail dot com |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58093
--- Comment #5 from Nick Maclaren nmm1 at cam dot ac.uk ---
I did. Please read what the C++ standard says about conversions. 4.7
[conv.integral] paragraph 2 is a paraphrase of wording that has been in
every C and C++ compiler since C90, and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
--- Comment #15 from Andrew Benson abensonca at gmail dot com ---
Thanks for fixing!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57602
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #37 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
this version fixes the warning:
--- ../gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c 2013-08-02
20:59:38.0 +0200
+++ pr58041.c 2013-08-06
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58092
--- Comment #5 from Mikael Pettersson mikpe at it dot uu.se ---
I can't reproduce the wrong-code with 4.6.4. 4.7.2, or 4.8.1. They all
generate:
test:
0: 24020002li v0,2
4: aca2sw v0,0(a1)
8:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58095
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org ---
I've tried using __restrict__ keyword for input data (foo2),
I think you want __restrict__ inside of the [].
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35300
Kai Tietz ktietz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #38 from Martin Jambor jamborm at gcc dot gnu.org ---
(In reply to Bernd Edlinger from comment #37)
this version fixes the warning:
And I confirm that it still tests the bug. If you want to commit it
yourself, go ahead, otherwise
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46501
Kai Tietz ktietz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35300
Kai Tietz ktietz at gcc dot gnu.org changed:
What|Removed |Added
CC||nightstrike at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #39 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Martin Jambor from comment #38)
(In reply to Bernd Edlinger from comment #37)
this version fixes the warning:
And I confirm that it still tests the bug. If
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58093
--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Nick Maclaren from comment #5)
I did. Please read what the C++ standard says about conversions. 4.7
[conv.integral] paragraph 2 is a paraphrase of wording that has
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
Martin Jambor jamborm at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58095
--- Comment #2 from Siavash Eliasi siavashserver at gmail dot com ---
(In reply to Andrew Pinski from comment #1)
I've tried using __restrict__ keyword for input data (foo2),
I think you want __restrict__ inside of the [].
Do you mind pasting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58088
--- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org ---
Kyrylo, do you plan to work on this? If that's the case, please assign the bug
to yourself.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #41 from Bill Schmidt wschmidt at gcc dot gnu.org ---
Thanks, Martin!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58088
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot
Con il DECRETO-LEGGE 8 aprile 2013, n. 35
in cui il Consiglio dei Ministri anticipa i pagamenti alle P.A. e aiuti per le
famiglie,
Carrefour Spa ti consente di acquistare la carta Prepagata SpesAmica del valore
di 500 Euro
al prezzo di 100 Euro.
(80% rimborsato dal Ministero dello Sviluppo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067
Alexandre Oliva aoliva at gcc dot gnu.org changed:
What|Removed |Added
CC||aoliva at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58084
Pat Haugen pthaugen at gcc dot gnu.org changed:
What|Removed |Added
Target|arm-none-eabi |arm-none-eabi,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #18 from David Abdurachmanov david.abdurachmanov at gmail dot com
---
Tested the patch on top of final 4.8.1 Cortex-A9 NEON FPU. GCC no more ICE'ing
while compiling scipy.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58096
Bug ID: 58096
Summary: gcc.dg/tree-ssa/attr-alias.c fails with r201439
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58079
rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58092
--- Comment #6 from Rafał Miłecki zajec5 at gmail dot com ---
OK, I've installed cross-mips-linux-gcc package from:
http://download.opensuse.org/repositories/home:/duwe:/crosstools/openSUSE_12.2/
and it works. After compiling test.c with:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58079
rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067
--- Comment #5 from Alexandre Oliva aoliva at gcc dot gnu.org ---
As Andrew says, the problem with -mtls-dialect=gnu (the default) is lack of TLS
support. The tls_get_addr calls expanded by tls_global_dynamic_64_mode are
not recognized by the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58034
--- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Wed, 31 Jul 2013, amodra at gmail dot com wrote:
The relevant test case source:
if (setjmp (jmpbuf))
{
puts (Exiting main...);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
--- Comment #3 from Paul Pluzhnikov ppluzhnikov at google dot com ---
(In reply to Paul Pluzhnikov from comment #2)
What is the way to turn it on?
Compiling test case with -mtls-dialect=gnu2 does appear to improve the picture:
g++ -fPIC -O2 -S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58096
David Edelsohn dje at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067
--- Comment #6 from Ben Woodard woodard at redhat dot com ---
I just rebuilt the trunk with the patch that Alexandre Oliva provided and I can
confirm that it solves the problem with notes about non-delegitimized
addresses.
However, I haven't yet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067
--- Comment #7 from Ben Woodard woodard at redhat dot com ---
Created attachment 30622
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30622action=edit
Alexandre's patch as a file rather than as text.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57825
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56979
--- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Sat, 3 Aug 2013, rearnsha at gcc dot gnu.org wrote:
Although the compiler shouldn't ICE, it's arguable that passing over-aligned
values by value to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57956
DJ Delorie dj at redhat dot com changed:
What|Removed |Added
CC||dj at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57850
--- Comment #7 from Sharad Singhai singhai at gcc dot gnu.org ---
I looked at it and this issue seems related to handling of PCH files. The
following patch introduced it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57255
Bug 57255 depends on bug 57825, which changed state.
Bug 57825 Summary: Template specialization for ref qualified member pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57825
What|Removed |Added
1 - 100 of 201 matches
Mail list logo
