Re: [RFC] Meta-description for tree and gimple folding
On Tue, 4 Mar 2014, Marc Glisse wrote: On Mon, 3 Mar 2014, Richard Biener wrote: How do I restrict some subexpression to have a single use? This kind of restrictions come via the valueize() hook - simply valueize to NULL_TREE to make the match fail (for example SSA_NAME_OCCURS_IN_ABNORMAL_PHI could be made fail that way). Shouldn't that single-use property depend more on the transformation and less on where it is called from? a+b-b - a is always going to be a good idea (well, register pressure aside), even if a+b is used in many other places. But if you are using a*b elsewhere, turning a*b+c into FMA doesn't make so much sense. Yeah, that's true. Well, we can always call has_single_use on some @i if it is an SSA_NAME. Sure. As I have to add the capability to guard patterns with flags doing an additional has_single_use test there is easy (but of course that's something only available when in SSA form - something to keep in mind if we also want to create a GENERIC variant of the transform). Note that the concept of having a single-use makes whether a pattern matches possibly dependent on the order of processing uses and dependent on dead code being removed. Just sth to keep in mind if you want the maximum number of transforms rather than being cautious by default. If I write a COND_EXPR matcher, could it generate code for phiopt as well? Not sure, what do you have in mind specifically? fold-const.c has the equivalent of: (define_match_and_simplify abs (COND_EXPR (LT_EXPR @0 zero_p) (NEGATE_EXPR @0) @0) (ABS_EXPR @0)) (it would help to be able to write LT_EXPR|LE_EXPR, maybe even to try automatically simplify(!a)?c:b for a?b:c) which works well on trees, but requires more complicated code in phiopt (same for min/max). Yeah, inventing short-cuts for stuff like LT_EXPR|LE_EXPR or (PLUS_EXPR sub-expr1 sub-expr2) vs. (PLUS_EXPR sub-expr2 sub-expr1) is on my list. In the end it will (internally) duplicate the pattern to have one for each variant. I'm still pondering over the exact syntax for both (I can easily add builtin knowledge for commutative operators of course). Eventually the preprocessor comes to our rescue here ... #define X(CMP) \ (define_match_and_simplify \ ((COND_EXPR (CMP @0 zero_p) (NEGATE_EXPR @0) @0) \ (ABS_EXPR @0)) X(LT_EXPR) X(LE_EXPR) uglier than sth like (define_op LT_OR_LE_EXPR LT_EXPR|LE_EXPR) (define_match_and_simplify ((COND_EXPR (LT_OR_LE_EXPR @0 zero_p) ... or what you proposed. But how do you handle (BIT_IOR_EXPR (LT_EXPR|LE_EXPR @0 @1) (GE_EXPR|GT_EXPR @0 @1)) for example? a) Match variants in lock-step? b) Have the above generate 4 variants? c) Disallow it (looks error-prone)? I'd rather keep it simple for now ;) How do you handle a transformation that currently tries to recursively fold something else and does the main transformation only if that simplified? And doesn't do the other folding (because it's not in the IL literally?)? Similar to the cst without overflow case, by writing custom C code and allowing that to signal failure. I am not sure if it will be easy to write code that works for generic and gimple. I'll see... That's true - though GIMPLE and GENERIC share trees which makes it easy enough for most of the cases. We'll see ... For now I'm concentrating of fitting the framework into forwprop, replacing manual patterns that occur there. Richard.
Re: linux says it is a bug
On 03/04/2014 10:12 PM, Yury Gribov wrote: Asms without outputs are automatically volatile. So there ought be zero change with and without the explicit use of the __volatile__ keyword. That’s what the documentation says but it wasn’t actually true as of a couple of releases ago, as I recall. Looks like 2005: $ git annotate gcc/c/c-typeck.c ... 89552023( bonzini 2005-10-05 12:17:16 + 9073) /* asm statements without outputs, including simple ones, are treated 89552023( bonzini 2005-10-05 12:17:16 + 9074) as volatile. */ 89552023( bonzini 2005-10-05 12:17:16 + 9075) ASM_INPUT_P (args) = simple; 89552023( bonzini 2005-10-05 12:17:16 + 9076) ASM_VOLATILE_P (args) = (noutputs == 0); Yep, that's the one. So, more than a couple of releases: gcc 4.2 and later. r~
Re: linux says it is a bug
On Mar 5, 2014, at 10:07 AM, Richard Henderson r...@redhat.com wrote: On 03/04/2014 10:12 PM, Yury Gribov wrote: Asms without outputs are automatically volatile. So there ought be zero change with and without the explicit use of the __volatile__ keyword. That’s what the documentation says but it wasn’t actually true as of a couple of releases ago, as I recall. Looks like 2005: $ git annotate gcc/c/c-typeck.c ... 89552023( bonzini 2005-10-05 12:17:16 + 9073) /* asm statements without outputs, including simple ones, are treated 89552023( bonzini 2005-10-05 12:17:16 + 9074) as volatile. */ 89552023( bonzini 2005-10-05 12:17:16 + 9075) ASM_INPUT_P (args) = simple; 89552023( bonzini 2005-10-05 12:17:16 + 9076) ASM_VOLATILE_P (args) = (noutputs == 0); Yep, that's the one. So, more than a couple of releases: gcc 4.2 and later. Thanks gentlemen. That explains it — we ran into this in GCC 3.3.3 and then upgraded from there straight to V4.6 or so. paul
RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
From: Thomas Preud'homme [Since I can now send emails without disclaimers, I registered to the mailing list with my work email. Thus no need to CC me anymore.] Failed in the previous 2 emails. Sorry about that.
RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
[Since I can now send emails without disclaimers, I registered to the mailing list with my work email. Thus no need to CC me anymore.] My apologize for the line length, the MUA says it all I think. It seems to ignore my word wrap setting From: Joseph Myers [mailto:jos...@codesourcery.com] Sent: Wednesday, March 05, 2014 2:13 AM If the function is only declared and not called or defined (in a system header etc.), of course you don't want that to affect the ABI (even in the case of an inline function in a system header, unless an out-of-line call is generated to it). But a call to a function not defined in that unit does affect the ABI compatibility, if the call involves affected types. This should be fine with the current implementation as I did the check inside the hooks TARGET_FUNCTION_ARG, TARGET_FUNCTION_VALUE and INIT_CUMULATIVE_ARG. The two former allow to test whether a parameter or a return value is a float while the latter is used to test whether the float ABI actually matters. INIT_CUMULATIVE_ARG is called when knowing where a parameter ends up matters, so when a function is defined (not declared) or when it is called. Checking whether the function is static or variadic allow to have a complete check. Inlining does not need any additional check since if the function is inlined there is no call and if not there will be a call and the current checks will catch it. However, one thing I did not do is look in function calls if the return value is ignored or not. If it is ignored the float ABI does not matter. Some libgcc functions on ARM have ABIs that depend on which AAPCS variant is in use - that is, libcalls, not just explicitly defined or called functions, can affect the ABI compatibility. But the RTABI functions don't - if you allow for that, then you increase the number of cases that end up compatible with both ABI variants. Do you have some example of such libgcc functions? Is there any of them with no link to the use of float in public interface? Without knowing any such case from the top of my head I would say that the use of any of these functions make the compilation unit not compatible with both calling conventions since it requires libgcc for a specific calling convention but maybe the runtime library can be treated differently than other libraries. On ARM, variadic functions use only the base AAPCS and so don't affect compatibility even if they have floating-point (or vector) arguments. (This is something that's different on some other architectures with similar issues.) Yep I took this into consideration. Best regards, Thomas
RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
From: Richard Sandiford [mailto:rdsandif...@googlemail.com] Yeah, that'd be great. The checking that MIPS's -mno-float should do (but doesn't do) would be a superset of what you need, since the MIPS case would include internal uses of floats. But it would definitely make sense to share the bits that can be shared and (for example) to get consistent error messages for them. I agree on the error messages and on a common switch. I am not sure for the rest though (see below). How about warning for all float types (as the float option) and all vector types (as a separate option)? I'm not sure there's as much value in warning specifically about hardware types since that can always change in future. E.g. a while ago the only MIPS vector of interest was V2SF, but then Loongson added some integer ones, and now MSA is adding 128-bit vector types. There could be wider types in future, as happened for 512-bit AVX. I do not think it is a good approach. First, it means on ARM a user would need to use several switches to test compatibility and at least one part would be ARM specific (vector of less than 4 float/double). Second, when the function is variadic ARM use the base calling convention, no matter what is the calling convention normally used. So a float in a variadic function is not a problem for ARM but might be a problem for MIPS. I agree though that there is an overlap with the -no-float switch of MIPS. On the other hand checking for the dual compatibility of an ARM code is just about 15 lines of code and doing this in middle end with some hooks for architecture specific bits would make the code much bigger I think. I'll think some more about it and give you a more decided opinion. Right now my mind is not set. -mno-float as it stands today is really just -msoft-float with some floating-point support removed from the library to save space. One of the important examples is that the floating-point printf and scanf formats are not supported, so printf and scanf do not pull in large parts of the software floating-point library. But the restrictions that apply to -mno-float should make it link-compatible with -mhard-float too, as for your use case. Right. With your explanation and the description of the -mno-float switch I now understand what it does. So as I said, there is an important overlap with my work and if I can find an approach that manage to share some code I will do that. I am unsure at present about whether it is a good thing to do. I believe a new switch is necessary since what I need for ARM is slightly different than -mno-float meaning. The logic could be partially shared if it is not too complicated to do so. Best regards, Thomas
Re: Help Required on Missing GOTO statements in Gimple/SSA/CFG Pass ...
Hi,
I am extremely sorry as I couldn't reply from many days. Actually I
was busy with some personal work so I didn't work for many days.
I didn't use MELT because, I didn't want learn a new language and
also my professor wanted me to code the plugin in C/C++ .
On 2/18/14, Basile Starynkevitch bas...@starynkevitch.net wrote:
On Tue, 2014-02-18 at 11:17 +0530, Mohsin Khan wrote:
Hi,
I am developing plugins for the GCC-4.8.2. I am a newbie in plugins.
I wrote a plugin and tried to count and see the Goto Statements using
the gimple_stmt_iterator. I get gimple statements printed on my
stdout, but I am not able to find the line which has goto statements.
I guess that most GOTOs are just becoming implicit as the link to the
next basic block.
Probably
if (!cond) goto end;
something;
end:;
has nearly the same Gimple representation than
while (cond) {
something;
}
BTW, did you consider using MELT http://gcc-melt.org/ to code your GCC
extension?
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Can Some one please help me on this gcc plugin..
Hi,
I am developing plugins for the GCC-4.8.2. I am a newbie in plugins.
I wrote a plugin and tried to count and see the Goto Statements using
the gimple_stmt_iterator. I get gimple statements printed on my
stdout, but I am not able to find the line which has goto statements.
I only get other lines such as variable declaration and logic
statements, but no goto statements.
When I open the Gimple/SSA/CFG file seperately using the vim editor
I find the goto statements are actually present.
So, can anyone help me. How can I actually get the count of Goto
statements or atleast access these goto statements using some
iterator.
I have used -fdump-tree-all, -fdump-tree-cfg as flags.
Here is the pseudocode:
struct register_pass_info pass_info = {
(pass_plugin.pass), /* Address of new pass,
here, the 'struct
opt_pass' field of
'gimple_opt_pass'
defined above */
ssa, /* Name of the reference
pass for hooking up
the new pass. ??? */
0, /* Insert the pass at the
specified instance
number of the reference
pass. Do it for
every instance if it is 0. */
PASS_POS_INSERT_AFTER/* how to insert the new
pass: before,
after, or replace. Here
we are inserting
a pass names 'plug' after
the pass named
'pta' */
};
.
static unsigned int dead_code_elimination (void)
{
FOR_EACH_BB_FN (bb, cfun)
{
// gimple_dump_bb(stdout,bb,0,0);
//printf(\nIn New BB);
gsi2= gsi_after_labels (bb);
print_gimple_stmt(stdout,gsi_stmt(gsi2),0,0);
/*Iterating over each gimple statement in a basic block*/
for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (gsi))
{
g = gsi_stmt(gsi);
print_gimple_stmt(stdout,g,0,0);
if (gimple_code(g)==GIMPLE_GOTO)
printf(\nFound GOTO stmt\n);
print_gimple_stmt(stdout,gsi_stmt(gsi),0,0);
//analyze_gimple_statement (gsi);
}
}
}
Re: [RFC][PATCH 0/5] arch: atomic rework
On Tue, 2014-03-04 at 11:00 -0800, Paul E. McKenney wrote:
On Mon, Mar 03, 2014 at 09:46:19PM +0100, Torvald Riegel wrote:
xagsmtp2.20140303204700.3...@vmsdvma.vnet.ibm.com
X-Xagent-Gateway: vmsdvma.vnet.ibm.com (XAGSMTP2 at VMSDVMA)
On Mon, 2014-03-03 at 11:20 -0800, Paul E. McKenney wrote:
On Mon, Mar 03, 2014 at 07:55:08PM +0100, Torvald Riegel wrote:
xagsmtp2.20140303190831.9...@uk1vsc.vnet.ibm.com
X-Xagent-Gateway: uk1vsc.vnet.ibm.com (XAGSMTP2 at UK1VSC)
On Fri, 2014-02-28 at 16:50 -0800, Paul E. McKenney wrote:
+oDo not use the results from the boolean and || when
+ dereferencing. For example, the following (rather improbable)
+ code is buggy:
+
+ int a[2];
+ int index;
+ int force_zero_index = 1;
+
+ ...
+
+ r1 = rcu_dereference(i1)
+ r2 = a[r1 force_zero_index]; /* BUGGY!!! */
+
+ The reason this is buggy is that and || are often
compiled
+ using branches. While weak-memory machines such as ARM or
PowerPC
+ do order stores after such branches, they can speculate loads,
+ which can result in misordering bugs.
+
+oDo not use the results from relational operators (==, !=,
+ , =, , or =) when dereferencing. For example,
+ the following (quite strange) code is buggy:
+
+ int a[2];
+ int index;
+ int flip_index = 0;
+
+ ...
+
+ r1 = rcu_dereference(i1)
+ r2 = a[r1 != flip_index]; /* BUGGY!!! */
+
+ As before, the reason this is buggy is that relational operators
+ are often compiled using branches. And as before, although
+ weak-memory machines such as ARM or PowerPC do order stores
+ after such branches, but can speculate loads, which can again
+ result in misordering bugs.
Those two would be allowed by the wording I have recently proposed,
AFAICS. r1 != flip_index would result in two possible values (unless
there are further constraints due to the type of r1 and the values that
flip_index can have).
And I am OK with the value_dep_preserving type providing more/better
guarantees than we get by default from current compilers.
One question, though. Suppose that the code did not want a value
dependency to be tracked through a comparison operator. What does
the developer do in that case? (The reason I ask is that I have
not yet found a use case in the Linux kernel that expects a value
dependency to be tracked through a comparison.)
Hmm. I suppose use an explicit cast to non-vdp before or after the
comparison?
That should work well assuming that things like if, while, and ?:
conditions are happy to take a vdp.
I currently don't see a reason why that should be disallowed. If we
have allowed an implicit conversion to non-vdp, I believe that should
follow. ?: could be somewhat special, in that the type depends on the
2nd and 3rd operand. Thus, vdp x = non-vdp ? vdp : vdp; should be
allowed, whereas vdp x = non-vdp ? non-vdp : vdp; probably should be
disallowed if we don't provide for implicit casts from non-vdp to vdp.
This assumes that p-a only returns
vdp if field a is declared vdp, otherwise we have vdps running wild
through the program. ;-)
That's a good question. For the scheme I had in mind, I'm not concerned
about vdps running wild because one needs to assign to explicitly
vdp-typed variables (or function arguments, etc.) to let vdp extend to
beyond single expressions.
Nonetheless, I think it's a good question how - should behave if the
field is not vdp; in particular, should vdp-non_vdp be automatically
vdp? One concern might be that we know something about non-vdp -- OTOH,
we shouldn't be able to do so because we (assume to) don't know anything
about the vdp pointer, so we can't infer something about something it
points to.
The other thing that can happen is that a vdp can get handed off to
another synchronization mechanism, for example, to reference counting:
p = atomic_load_explicit(gp, memory_order_consume);
if (do_something_with(p-a)) {
/* fast path protected by RCU. */
return 0;
}
if (atomic_inc_not_zero(p-refcnt) {
Is the argument to atomic_inc_no_zero vdp or non-vdp?
/* slow path protected by reference counting. */
return do_something_else_with((struct foo *)p); /* CHANGE */
}
/* Needed slow path, but raced with deletion. */
return -EAGAIN;
I am guessing that the cast ends the vdp. Is that the case?
That would end it, yes. The other way this could happen is that the
argument of do_something_else_with() would be specified to be non-vdp.
Re: Can Some one please help me on this gcc plugin..
On Wed, 2014-03-05 at 21:58 +0530, Mohsin Khan wrote:
Hi,
I am developing plugins for the GCC-4.8.2. I am a newbie in plugins.
I wrote a plugin and tried to count and see the Goto Statements using
the gimple_stmt_iterator. I get gimple statements printed on my
stdout, but I am not able to find the line which has goto statements.
I only get other lines such as variable declaration and logic
statements, but no goto statements.
When I open the Gimple/SSA/CFG file seperately using the vim editor
I find the goto statements are actually present.
So, can anyone help me. How can I actually get the count of Goto
statements or atleast access these goto statements using some
iterator.
I have used -fdump-tree-all, -fdump-tree-cfg as flags.
Here is the pseudocode:
struct register_pass_info pass_info = {
(pass_plugin.pass), /* Address of new pass,
here, the 'struct
opt_pass' field of
'gimple_opt_pass'
defined above */
ssa, /* Name of the reference
pass for hooking up
the new pass. ??? */
0, /* Insert the pass at the
specified instance
number of the reference
pass. Do it for
every instance if it is 0. */
PASS_POS_INSERT_AFTER/* how to insert the new
pass: before,
You're inserting your pass after the ssa pass, which converts the CFG
to SSA form. This is run *after* the function has been converted from a
flat list of gimple statements into a CFG of basic blocks, and that CFG
conversion eliminates the goto statements in favor of edges within the
CFG. If you see goto in the dump, that's presumably just a textual
way of expressing an edge in the CFG.
To see gimple goto statements, you need to run your pass *before* the
convertion to CFG, which happens fairly early on, in the cfg pass
FWIW there's a diagram showing the passes here:
http://gcc-python-plugin.readthedocs.org/en/latest/tables-of-passes.html
Hope this is helpful
Dave
Re: [RFC][PATCH 0/5] arch: atomic rework
On Tue, 2014-03-04 at 13:35 -0800, Paul E. McKenney wrote:
On Tue, Mar 04, 2014 at 11:00:32AM -0800, Paul E. McKenney wrote:
On Mon, Mar 03, 2014 at 09:46:19PM +0100, Torvald Riegel wrote:
xagsmtp2.20140303204700.3...@vmsdvma.vnet.ibm.com
X-Xagent-Gateway: vmsdvma.vnet.ibm.com (XAGSMTP2 at VMSDVMA)
On Mon, 2014-03-03 at 11:20 -0800, Paul E. McKenney wrote:
On Mon, Mar 03, 2014 at 07:55:08PM +0100, Torvald Riegel wrote:
xagsmtp2.20140303190831.9...@uk1vsc.vnet.ibm.com
X-Xagent-Gateway: uk1vsc.vnet.ibm.com (XAGSMTP2 at UK1VSC)
On Fri, 2014-02-28 at 16:50 -0800, Paul E. McKenney wrote:
+o Do not use the results from the boolean and || when
+ dereferencing. For example, the following (rather improbable)
+ code is buggy:
+
+ int a[2];
+ int index;
+ int force_zero_index = 1;
+
+ ...
+
+ r1 = rcu_dereference(i1)
+ r2 = a[r1 force_zero_index]; /* BUGGY!!! */
+
+ The reason this is buggy is that and || are often
compiled
+ using branches. While weak-memory machines such as ARM or
PowerPC
+ do order stores after such branches, they can speculate loads,
+ which can result in misordering bugs.
+
+o Do not use the results from relational operators (==, !=,
+ , =, , or =) when dereferencing. For example,
+ the following (quite strange) code is buggy:
+
+ int a[2];
+ int index;
+ int flip_index = 0;
+
+ ...
+
+ r1 = rcu_dereference(i1)
+ r2 = a[r1 != flip_index]; /* BUGGY!!! */
+
+ As before, the reason this is buggy is that relational operators
+ are often compiled using branches. And as before, although
+ weak-memory machines such as ARM or PowerPC do order stores
+ after such branches, but can speculate loads, which can again
+ result in misordering bugs.
Those two would be allowed by the wording I have recently proposed,
AFAICS. r1 != flip_index would result in two possible values (unless
there are further constraints due to the type of r1 and the values
that
flip_index can have).
And I am OK with the value_dep_preserving type providing more/better
guarantees than we get by default from current compilers.
One question, though. Suppose that the code did not want a value
dependency to be tracked through a comparison operator. What does
the developer do in that case? (The reason I ask is that I have
not yet found a use case in the Linux kernel that expects a value
dependency to be tracked through a comparison.)
Hmm. I suppose use an explicit cast to non-vdp before or after the
comparison?
That should work well assuming that things like if, while, and ?:
conditions are happy to take a vdp. This assumes that p-a only returns
vdp if field a is declared vdp, otherwise we have vdps running wild
through the program. ;-)
The other thing that can happen is that a vdp can get handed off to
another synchronization mechanism, for example, to reference counting:
p = atomic_load_explicit(gp, memory_order_consume);
if (do_something_with(p-a)) {
/* fast path protected by RCU. */
return 0;
}
if (atomic_inc_not_zero(p-refcnt) {
/* slow path protected by reference counting. */
return do_something_else_with((struct foo *)p); /* CHANGE */
}
/* Needed slow path, but raced with deletion. */
return -EAGAIN;
I am guessing that the cast ends the vdp. Is that the case?
And here is a more elaborate example from the Linux kernel:
struct md_rdev value_dep_preserving *rdev; /* CHANGE */
rdev = rcu_dereference(conf-mirrors[disk].rdev);
if (r1_bio-bios[disk] == IO_BLOCKED
|| rdev == NULL
|| test_bit(Unmerged, rdev-flags)
|| test_bit(Faulty, rdev-flags))
continue;
The fact that the rdev == NULL returns vdp does not force the ||
operators to be evaluated arithmetically because the entire function
is an if condition, correct?
That's a good question, and one that as far as I understand currently,
essentially boils down to whether we want to have tight restrictions on
which operations are still vdp.
If we look at the different combinations, then it seems we can't decide
on whether we have a value-dependency just due to a vdp type:
* non-vdp || vdp: vdp iff non-vdp == false
* vdp || non-vdp: vdp iff non-vdp == false?
* vdp || vdp: always vdp? (and dependency on both?)
I'm not sure it makes sense to try to not make all of those
vdp-by-default. The first and second case show that it's dependent on
the specific execution anyway, and thus is
Re: [RFC][PATCH 0/5] arch: atomic rework
On Tue, 2014-03-04 at 22:11 +, Peter Sewell wrote:
On 3 March 2014 20:44, Torvald Riegel trie...@redhat.com wrote:
On Sun, 2014-03-02 at 04:05 -0600, Peter Sewell wrote:
On 1 March 2014 08:03, Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
On Sat, Mar 01, 2014 at 04:06:34AM -0600, Peter Sewell wrote:
Hi Paul,
On 28 February 2014 18:50, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
On Thu, Feb 27, 2014 at 12:53:12PM -0800, Paul E. McKenney wrote:
On Thu, Feb 27, 2014 at 11:47:08AM -0800, Linus Torvalds wrote:
On Thu, Feb 27, 2014 at 11:06 AM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
3. The comparison was against another RCU-protected pointer,
where that other pointer was properly fetched using one
of the RCU primitives. Here it doesn't matter which
pointer
you use. At least as long as the rcu_assign_pointer()
for
that other pointer happened after the last update to the
pointed-to structure.
I am a bit nervous about #3. Any thoughts on it?
I think that it might be worth pointing out as an example, and
saying
that code like
p = atomic_read(consume);
X;
q = atomic_read(consume);
Y;
if (p == q)
data = p-val;
then the access of p-val is constrained to be data-dependent on
*either* p or q, but you can't really tell which, since the
compiler
can decide that the values are interchangeable.
I cannot for the life of me come up with a situation where this
would
matter, though. If X contains a fence, then that fence will be a
stronger ordering than anything the consume through p would
guarantee anyway. And if X does *not* contain a fence, then the
atomic reads of p and q are unordered *anyway*, so then whether the
ordering to the access through p is through p or q is kind of
irrelevant. No?
I can make a contrived litmus test for it, but you are right, the
only
time you can see it happen is when X has no barriers, in which case
you don't have any ordering anyway -- both the compiler and the CPU
can
reorder the loads into p and q, and the read from p-val can, as you
say,
come from either pointer.
For whatever it is worth, hear is the litmus test:
T1: p = kmalloc(...);
if (p == NULL)
deal_with_it();
p-a = 42; /* Each field in its own cache line. */
p-b = 43;
p-c = 44;
atomic_store_explicit(gp1, p, memory_order_release);
p-b = 143;
p-c = 144;
atomic_store_explicit(gp2, p, memory_order_release);
T2: p = atomic_load_explicit(gp2, memory_order_consume);
r1 = p-b; /* Guaranteed to get 143. */
q = atomic_load_explicit(gp1, memory_order_consume);
if (p == q) {
/* The compiler decides that q-c is same as p-c. */
r2 = p-c; /* Could get 44 on weakly order system. */
}
The loads from gp1 and gp2 are, as you say, unordered, so you get
what
you get.
And publishing a structure via one RCU-protected pointer, updating
it,
then publishing it via another pointer seems to me to be asking for
trouble anyway. If you really want to do something like that and
still
see consistency across all the fields in the structure, please put a
lock
in the structure and use it to guard updates and accesses to those
fields.
And here is a patch documenting the restrictions for the current Linux
kernel. The rules change a bit due to rcu_dereference() acting a bit
differently than atomic_load_explicit(p, memory_order_consume).
Thoughts?
That might serve as informal documentation for linux kernel
programmers about the bounds on the optimisations that you expect
compilers to do for common-case RCU code - and I guess that's what you
intend it to be for. But I don't see how one can make it precise
enough to serve as a language definition, so that compiler people
could confidently say yes, we respect that, which I guess is what
you really need. As a useful criterion, we should aim for something
precise enough that in a verified-compiler context you can
mathematically prove that the compiler will satisfy it (even though
that won't happen anytime soon for GCC), and that analysis tool
authors can actually know what they're working with. All this stuff
about you should avoid cancellation, and avoid masking with just a
small number of bits is just too vague.
Understood, and yes, this is intended to document current compiler
behavior for the Linux kernel community. It would not make sense to show
it to the C11 or C++11 communities, except perhaps as an
Re: [RFC][PATCH 0/5] arch: atomic rework
On Wed, Mar 05, 2014 at 05:26:36PM +0100, Torvald Riegel wrote: xagsmtp3.20140305162928.8...@uk1vsc.vnet.ibm.com X-Xagent-Gateway: uk1vsc.vnet.ibm.com (XAGSMTP3 at UK1VSC) On Tue, 2014-03-04 at 11:00 -0800, Paul E. McKenney wrote: On Mon, Mar 03, 2014 at 09:46:19PM +0100, Torvald Riegel wrote: xagsmtp2.20140303204700.3...@vmsdvma.vnet.ibm.com X-Xagent-Gateway: vmsdvma.vnet.ibm.com (XAGSMTP2 at VMSDVMA) On Mon, 2014-03-03 at 11:20 -0800, Paul E. McKenney wrote: On Mon, Mar 03, 2014 at 07:55:08PM +0100, Torvald Riegel wrote: xagsmtp2.20140303190831.9...@uk1vsc.vnet.ibm.com X-Xagent-Gateway: uk1vsc.vnet.ibm.com (XAGSMTP2 at UK1VSC) On Fri, 2014-02-28 at 16:50 -0800, Paul E. McKenney wrote: +o Do not use the results from the boolean and || when + dereferencing. For example, the following (rather improbable) + code is buggy: + + int a[2]; + int index; + int force_zero_index = 1; + + ... + + r1 = rcu_dereference(i1) + r2 = a[r1 force_zero_index]; /* BUGGY!!! */ + + The reason this is buggy is that and || are often compiled + using branches. While weak-memory machines such as ARM or PowerPC + do order stores after such branches, they can speculate loads, + which can result in misordering bugs. + +o Do not use the results from relational operators (==, !=, + , =, , or =) when dereferencing. For example, + the following (quite strange) code is buggy: + + int a[2]; + int index; + int flip_index = 0; + + ... + + r1 = rcu_dereference(i1) + r2 = a[r1 != flip_index]; /* BUGGY!!! */ + + As before, the reason this is buggy is that relational operators + are often compiled using branches. And as before, although + weak-memory machines such as ARM or PowerPC do order stores + after such branches, but can speculate loads, which can again + result in misordering bugs. Those two would be allowed by the wording I have recently proposed, AFAICS. r1 != flip_index would result in two possible values (unless there are further constraints due to the type of r1 and the values that flip_index can have). And I am OK with the value_dep_preserving type providing more/better guarantees than we get by default from current compilers. One question, though. Suppose that the code did not want a value dependency to be tracked through a comparison operator. What does the developer do in that case? (The reason I ask is that I have not yet found a use case in the Linux kernel that expects a value dependency to be tracked through a comparison.) Hmm. I suppose use an explicit cast to non-vdp before or after the comparison? That should work well assuming that things like if, while, and ?: conditions are happy to take a vdp. I currently don't see a reason why that should be disallowed. If we have allowed an implicit conversion to non-vdp, I believe that should follow. I am a bit nervous about a silent implicit conversion from vdp to non-vdp in the general case. However, when the result is being used by a conditional, the silent implicit conversion makes a lot of sense. Is that distinction something that the compiler can handle easily? On the other hand, silent implicit conversion from non-vdp to vdp is very useful for common code that can be invoked both by RCU readers and by updaters. ?: could be somewhat special, in that the type depends on the 2nd and 3rd operand. Thus, vdp x = non-vdp ? vdp : vdp; should be allowed, whereas vdp x = non-vdp ? non-vdp : vdp; probably should be disallowed if we don't provide for implicit casts from non-vdp to vdp. Actually, from the Linux-kernel code that I am seeing, we want to be able to silently convert from non-vdp to vdp in order to permit common code that is invoked from both RCU readers (vdp) and updaters (often non-vdp). This common code must be compiled conservatively to allow vdp, but should be just find with non-vdp. Going through the combinations... 0. vdp x = vdp ? vdp : vdp; /* OK, matches. */ 1. vdp x = vdp ? vdp : non-vdp; /* Silent conversion. */ 2. vdp x = vdp ? non-vdp : vdp; /* Silent conversion. */ 3. vdp x = vdp ? non-vdp : non-vdp; /* Silent conversion. */ 4. vdp x = non-vdp ? vdp : vdp; /* OK, matches. */ 5. vdp x = non-vdp ? vdp : non-vdp; /* Silent conversion. */ 6. vdp x = non-vdp ? non-vdp : vdp; /* Silent conversion. */ 7. vdp x = non-vdp ? non-vdp : non-vdp; /* Silent conversion. */ 8. non-vdp x = vdp ? vdp : vdp;
RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
On Wed, 5 Mar 2014, Thomas Preud'homme wrote: Some libgcc functions on ARM have ABIs that depend on which AAPCS variant is in use - that is, libcalls, not just explicitly defined or called functions, can affect the ABI compatibility. But the RTABI functions don't - if you allow for that, then you increase the number of cases that end up compatible with both ABI variants. Do you have some example of such libgcc functions? Is there any of them with no link to the use of float in public interface? Without knowing any such case from the top of my head I would say that the use of any of these functions make the compilation unit not compatible with both calling conventions since it requires libgcc for a specific calling convention but maybe the runtime library can be treated differently than other libraries. The functions affected use floating-point in their public interfaces - for example, __muldc3. Note that libcalls have a different hook (TARGET_LIBCALL_VALUE, ending up using arm_libcall_uses_aapcs_base) from the ones you mentioned. But if you use only functions that pass arm_libcall_uses_aapcs_base (i.e. the floating-point operations defined in RTABI) or don't involve floating point, then you can be compatible with both calling conventions. -- Joseph S. Myers jos...@codesourcery.com
Re: [RFC][PATCH 0/5] arch: atomic rework
On Wed, Mar 05, 2014 at 05:54:59PM +0100, Torvald Riegel wrote:
On Tue, 2014-03-04 at 13:35 -0800, Paul E. McKenney wrote:
On Tue, Mar 04, 2014 at 11:00:32AM -0800, Paul E. McKenney wrote:
On Mon, Mar 03, 2014 at 09:46:19PM +0100, Torvald Riegel wrote:
xagsmtp2.20140303204700.3...@vmsdvma.vnet.ibm.com
X-Xagent-Gateway: vmsdvma.vnet.ibm.com (XAGSMTP2 at VMSDVMA)
On Mon, 2014-03-03 at 11:20 -0800, Paul E. McKenney wrote:
On Mon, Mar 03, 2014 at 07:55:08PM +0100, Torvald Riegel wrote:
xagsmtp2.20140303190831.9...@uk1vsc.vnet.ibm.com
X-Xagent-Gateway: uk1vsc.vnet.ibm.com (XAGSMTP2 at UK1VSC)
On Fri, 2014-02-28 at 16:50 -0800, Paul E. McKenney wrote:
+oDo not use the results from the boolean and ||
when
+ dereferencing. For example, the following (rather improbable)
+ code is buggy:
+
+ int a[2];
+ int index;
+ int force_zero_index = 1;
+
+ ...
+
+ r1 = rcu_dereference(i1)
+ r2 = a[r1 force_zero_index]; /* BUGGY!!! */
+
+ The reason this is buggy is that and || are often
compiled
+ using branches. While weak-memory machines such as ARM or
PowerPC
+ do order stores after such branches, they can speculate loads,
+ which can result in misordering bugs.
+
+oDo not use the results from relational operators (==,
!=,
+ , =, , or =) when dereferencing. For example,
+ the following (quite strange) code is buggy:
+
+ int a[2];
+ int index;
+ int flip_index = 0;
+
+ ...
+
+ r1 = rcu_dereference(i1)
+ r2 = a[r1 != flip_index]; /* BUGGY!!! */
+
+ As before, the reason this is buggy is that relational operators
+ are often compiled using branches. And as before, although
+ weak-memory machines such as ARM or PowerPC do order stores
+ after such branches, but can speculate loads, which can again
+ result in misordering bugs.
Those two would be allowed by the wording I have recently proposed,
AFAICS. r1 != flip_index would result in two possible values
(unless
there are further constraints due to the type of r1 and the values
that
flip_index can have).
And I am OK with the value_dep_preserving type providing more/better
guarantees than we get by default from current compilers.
One question, though. Suppose that the code did not want a value
dependency to be tracked through a comparison operator. What does
the developer do in that case? (The reason I ask is that I have
not yet found a use case in the Linux kernel that expects a value
dependency to be tracked through a comparison.)
Hmm. I suppose use an explicit cast to non-vdp before or after the
comparison?
That should work well assuming that things like if, while, and ?:
conditions are happy to take a vdp. This assumes that p-a only returns
vdp if field a is declared vdp, otherwise we have vdps running wild
through the program. ;-)
The other thing that can happen is that a vdp can get handed off to
another synchronization mechanism, for example, to reference counting:
p = atomic_load_explicit(gp, memory_order_consume);
if (do_something_with(p-a)) {
/* fast path protected by RCU. */
return 0;
}
if (atomic_inc_not_zero(p-refcnt) {
/* slow path protected by reference counting. */
return do_something_else_with((struct foo *)p); /* CHANGE */
}
/* Needed slow path, but raced with deletion. */
return -EAGAIN;
I am guessing that the cast ends the vdp. Is that the case?
And here is a more elaborate example from the Linux kernel:
struct md_rdev value_dep_preserving *rdev; /* CHANGE */
rdev = rcu_dereference(conf-mirrors[disk].rdev);
if (r1_bio-bios[disk] == IO_BLOCKED
|| rdev == NULL
|| test_bit(Unmerged, rdev-flags)
|| test_bit(Faulty, rdev-flags))
continue;
The fact that the rdev == NULL returns vdp does not force the ||
operators to be evaluated arithmetically because the entire function
is an if condition, correct?
That's a good question, and one that as far as I understand currently,
essentially boils down to whether we want to have tight restrictions on
which operations are still vdp.
If we look at the different combinations, then it seems we can't decide
on whether we have a value-dependency just due to a vdp type:
* non-vdp || vdp: vdp iff non-vdp == false
* vdp || non-vdp: vdp iff non-vdp == false?
* vdp || vdp: always vdp? (and dependency on both?)
I'm not sure it makes sense to try to not make
Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Matthew Fortune matthew.fort...@imgtec.com writes: Are you're OK with automatically selecting fpxx if no -mfp option, no .module and no .gnu_attribute exists? Such code would currently end up as FP ABI Any even if FP code was present, I don't suppose anything would get worse if this existing behaviour simply continued though. The -mfp setting is usually implied by the -mabi setting. I don't think we should change that. Since this is a new mode, and since the fpxx markup will be available from the start, everyone using fpxx should say so explicitly. E.g. maybe the rules should be: (1) Any explicit .gnu_attribute 4 is always used, although we might give a diagnostic if it's incompatible with the module-level setting. (2) Otherwise, if the code does not use FP then the attribute is left at the default of 0. (3) Otherwise, a nonzero .gnu_attribute 4 is implied from the module-level setting. (4) For compatibility, -mabi=32 continues to imply -mfp32. fpxx mode must be selected explicitly. Which was supposed to be simple, but maybe isn't so much. Thanks, Richard
Re: [RFC][PATCH 0/5] arch: atomic rework
On 5 March 2014 17:15, Torvald Riegel trie...@redhat.com wrote:
On Tue, 2014-03-04 at 22:11 +, Peter Sewell wrote:
On 3 March 2014 20:44, Torvald Riegel trie...@redhat.com wrote:
On Sun, 2014-03-02 at 04:05 -0600, Peter Sewell wrote:
On 1 March 2014 08:03, Paul E. McKenney paul...@linux.vnet.ibm.com
wrote:
On Sat, Mar 01, 2014 at 04:06:34AM -0600, Peter Sewell wrote:
Hi Paul,
On 28 February 2014 18:50, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
On Thu, Feb 27, 2014 at 12:53:12PM -0800, Paul E. McKenney wrote:
On Thu, Feb 27, 2014 at 11:47:08AM -0800, Linus Torvalds wrote:
On Thu, Feb 27, 2014 at 11:06 AM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
3. The comparison was against another RCU-protected
pointer,
where that other pointer was properly fetched using one
of the RCU primitives. Here it doesn't matter which
pointer
you use. At least as long as the rcu_assign_pointer()
for
that other pointer happened after the last update to the
pointed-to structure.
I am a bit nervous about #3. Any thoughts on it?
I think that it might be worth pointing out as an example, and
saying
that code like
p = atomic_read(consume);
X;
q = atomic_read(consume);
Y;
if (p == q)
data = p-val;
then the access of p-val is constrained to be data-dependent on
*either* p or q, but you can't really tell which, since the
compiler
can decide that the values are interchangeable.
I cannot for the life of me come up with a situation where this
would
matter, though. If X contains a fence, then that fence will be a
stronger ordering than anything the consume through p would
guarantee anyway. And if X does *not* contain a fence, then the
atomic reads of p and q are unordered *anyway*, so then whether
the
ordering to the access through p is through p or q is kind of
irrelevant. No?
I can make a contrived litmus test for it, but you are right, the
only
time you can see it happen is when X has no barriers, in which case
you don't have any ordering anyway -- both the compiler and the CPU
can
reorder the loads into p and q, and the read from p-val can, as
you say,
come from either pointer.
For whatever it is worth, hear is the litmus test:
T1: p = kmalloc(...);
if (p == NULL)
deal_with_it();
p-a = 42; /* Each field in its own cache line. */
p-b = 43;
p-c = 44;
atomic_store_explicit(gp1, p, memory_order_release);
p-b = 143;
p-c = 144;
atomic_store_explicit(gp2, p, memory_order_release);
T2: p = atomic_load_explicit(gp2, memory_order_consume);
r1 = p-b; /* Guaranteed to get 143. */
q = atomic_load_explicit(gp1, memory_order_consume);
if (p == q) {
/* The compiler decides that q-c is same as p-c. */
r2 = p-c; /* Could get 44 on weakly order system. */
}
The loads from gp1 and gp2 are, as you say, unordered, so you get
what
you get.
And publishing a structure via one RCU-protected pointer, updating
it,
then publishing it via another pointer seems to me to be asking for
trouble anyway. If you really want to do something like that and
still
see consistency across all the fields in the structure, please put
a lock
in the structure and use it to guard updates and accesses to those
fields.
And here is a patch documenting the restrictions for the current
Linux
kernel. The rules change a bit due to rcu_dereference() acting a bit
differently than atomic_load_explicit(p, memory_order_consume).
Thoughts?
That might serve as informal documentation for linux kernel
programmers about the bounds on the optimisations that you expect
compilers to do for common-case RCU code - and I guess that's what you
intend it to be for. But I don't see how one can make it precise
enough to serve as a language definition, so that compiler people
could confidently say yes, we respect that, which I guess is what
you really need. As a useful criterion, we should aim for something
precise enough that in a verified-compiler context you can
mathematically prove that the compiler will satisfy it (even though
that won't happen anytime soon for GCC), and that analysis tool
authors can actually know what they're working with. All this stuff
about you should avoid cancellation, and avoid masking with just a
small number of bits is just too vague.
Understood, and yes, this is intended to document current compiler
behavior for the Linux kernel community. It would not make
RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Richard Sandiford rdsandif...@googlemail.com writes: Matthew Fortune matthew.fort...@imgtec.com writes: Are you're OK with automatically selecting fpxx if no -mfp option, no .module and no .gnu_attribute exists? Such code would currently end up as FP ABI Any even if FP code was present, I don't suppose anything would get worse if this existing behaviour simply continued though. The -mfp setting is usually implied by the -mabi setting. I don't think we should change that. Since this is a new mode, and since the fpxx markup will be available from the start, everyone using fpxx should say so explicitly. E.g. maybe the rules should be: (1) Any explicit .gnu_attribute 4 is always used, although we might give a diagnostic if it's incompatible with the module-level setting. (2) Otherwise, if the code does not use FP then the attribute is left at the default of 0. (3) Otherwise, a nonzero .gnu_attribute 4 is implied from the module- level setting. (4) For compatibility, -mabi=32 continues to imply -mfp32. fpxx mode must be selected explicitly. Which was supposed to be simple, but maybe isn't so much. This sounds OK. I'd rather (4) permitted transition to fpxx for 'safe' FP code but let's see if we can do without it. Setjmp/longjmp are the only obvious candidates for using FP code in assembly files and these need to transition to fpxx. The glibc implementation of setjmp/longjmp is in C so the new defaults from the compiler will lead to this being fpxx as -mips32r2 will imply -mfpxx so that is OK, these modules will be tagged as fpxx. Currently newlib's implementation is assembly code with no .gnu_attributes. Under the rules above this would start to be implicitly tagged as gnu_attribute 4,1 (fp32). Any thoughts on how we transition this to fpxx and still have the modules buildable with old tools as well? I'm not sure if it will be acceptable to say that it has to be rewritten in C. There will also be uclibc and bionic to deal with too for setjmp/longjmp but I don't have their source to hand. Regards, Matthew
Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Matthew Fortune matthew.fort...@imgtec.com writes:
Richard Sandiford rdsandif...@googlemail.com writes:
Matthew Fortune matthew.fort...@imgtec.com writes:
Are you're OK with automatically selecting fpxx if no -mfp option, no
.module and no .gnu_attribute exists? Such code would currently end up
as FP ABI Any even if FP code was present, I don't suppose anything
would get worse if this existing behaviour simply continued though.
The -mfp setting is usually implied by the -mabi setting. I don't think
we should change that. Since this is a new mode, and since the fpxx
markup will be available from the start, everyone using fpxx should say
so explicitly.
E.g. maybe the rules should be:
(1) Any explicit .gnu_attribute 4 is always used, although we might
give a diagnostic if it's incompatible with the module-level
setting.
(2) Otherwise, if the code does not use FP then the attribute is left
at the default of 0.
(3) Otherwise, a nonzero .gnu_attribute 4 is implied from the module-
level
setting.
(4) For compatibility, -mabi=32 continues to imply -mfp32. fpxx mode
must
be selected explicitly.
Which was supposed to be simple, but maybe isn't so much.
This sounds OK. I'd rather (4) permitted transition to fpxx for 'safe'
FP code but let's see if we can do without it. Setjmp/longjmp are the
only obvious candidates for using FP code in assembly files and these
need to transition to fpxx.
The glibc implementation of setjmp/longjmp is in C so the new defaults
from the compiler will lead to this being fpxx as -mips32r2 will imply
-mfpxx so that is OK, these modules will be tagged as fpxx.
Hmm, I don't think -mips32r2 should make any difference here.
You've specified it so that fpxx will work with MIPS II and above
and I'd prefer not to have an architecture option implicitly changing
the ABI. (They sometimes did in the long-distant past but it just
led to confusion.)
I think instead we should have a configuration switch that allows
a particular -mfp option to be inserted alongside -mabi=32 if no explicit
-mfp is given. This is how most --with options work. Maybe
--with-fp-32={32|64|xx}? Specific triples could set a default value if
they like. E.g. the MTI, SDE and mipsisa* ones would probably want to
default to --with-32-fp=xx. Triples aimed at MIPS IV and below would
stay as they are. (MIPS IV is sometimes used with -mabi=32.)
--with-fp-32 isn't the greatest name but is at least consistent with
--with-arch-32 and -mabi=32. Maybe --with-fp-32=64 is so weird
that breaking consistency is better though.
Currently newlib's implementation is assembly code with no
.gnu_attributes. Under the rules above this would start to be implicitly
tagged as gnu_attribute 4,1 (fp32). Any thoughts on how we transition
this to fpxx and still have the modules buildable with old tools as
well? I'm not sure if it will be acceptable to say that it has to be
rewritten in C.
If it's assembled as -mfpxx then it'll be implicitly tagged with the
new .gnu_attribute rather than 4,1. If it's not assembled as -mfpxx
then 4,1 would be the right choice.
Thanks,
Richard
RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Richard Sandiford rdsandif...@googlemail.com writes:
Matthew Fortune matthew.fort...@imgtec.com writes:
Richard Sandiford rdsandif...@googlemail.com writes:
Matthew Fortune matthew.fort...@imgtec.com writes:
Are you're OK with automatically selecting fpxx if no -mfp option,
no .module and no .gnu_attribute exists? Such code would currently
end up as FP ABI Any even if FP code was present, I don't suppose
anything would get worse if this existing behaviour simply
continued though.
The -mfp setting is usually implied by the -mabi setting. I don't
think we should change that. Since this is a new mode, and since the
fpxx markup will be available from the start, everyone using fpxx
should say so explicitly.
E.g. maybe the rules should be:
(1) Any explicit .gnu_attribute 4 is always used, although we might
give a diagnostic if it's incompatible with the module-level
setting.
(2) Otherwise, if the code does not use FP then the attribute is left
at the default of 0.
(3) Otherwise, a nonzero .gnu_attribute 4 is implied from the module-
level
setting.
(4) For compatibility, -mabi=32 continues to imply -mfp32. fpxx mode
must
be selected explicitly.
Which was supposed to be simple, but maybe isn't so much.
This sounds OK. I'd rather (4) permitted transition to fpxx for 'safe'
FP code but let's see if we can do without it. Setjmp/longjmp are the
only obvious candidates for using FP code in assembly files and these
need to transition to fpxx.
The glibc implementation of setjmp/longjmp is in C so the new defaults
from the compiler will lead to this being fpxx as -mips32r2 will imply
-mfpxx so that is OK, these modules will be tagged as fpxx.
Hmm, I don't think -mips32r2 should make any difference here.
You've specified it so that fpxx will work with MIPS II and above and
I'd prefer not to have an architecture option implicitly changing the
ABI. (They sometimes did in the long-distant past but it just led to
confusion.)
I didn't mean to single out mips32r2 here it applies equally to anything except
mips1 with O32.
I think instead we should have a configuration switch that allows a
particular -mfp option to be inserted alongside -mabi=32 if no explicit
-mfp is given. This is how most --with options work. Maybe --with-fp-
32={32|64|xx}? Specific triples could set a default value if they like.
E.g. the MTI, SDE and mipsisa* ones would probably want to default to --
with-32-fp=xx. Triples aimed at MIPS IV and below would stay as they
are. (MIPS IV is sometimes used with -mabi=32.)
--with-fp-32 isn't the greatest name but is at least consistent with
--with-arch-32 and -mabi=32. Maybe --with-fp-32=64 is so weird that
breaking consistency is better though.
Tying the use of fpxx by default to a configure time setting is OK with me.
When enabled it would still have to follow the rules as defined in the design
in that it can only apply to architectures that can support the variant.
Currently that means everything but mips1. I'm not sure this is the same as
tying an ABI to an architecture as both fp32 and fpxx are O32 and link
compatible. Perhaps the configure switch would be --with-o32-fp={32|64|xx}.
This shows it is just an O32 related setting.
Currently newlib's implementation is assembly code with no
.gnu_attributes. Under the rules above this would start to be
implicitly tagged as gnu_attribute 4,1 (fp32). Any thoughts on how we
transition this to fpxx and still have the modules buildable with old
tools as well? I'm not sure if it will be acceptable to say that it
has to be rewritten in C.
If it's assembled as -mfpxx then it'll be implicitly tagged with the new
.gnu_attribute rather than 4,1. If it's not assembled as -mfpxx then
4,1 would be the right choice.
So this would be dependent on the build system ensuring -mfpxx is passed as
appropriate if the toolchain supports it. There is some risk in this too if the
existing code (which I know is not fpxx safe) gets built with a new toolchain
then it will be tagged as fpxx. I wonder if this tells us that command line
options cannot safely set the FP ABI away from the default. Instead only the
.module and .gnu_attribute can set it as only the source code can know what FP
mode it was written for. The change to your 4 points above would be that the
module level setting is not impacted by the command line -mfp options.
This would then require us to have an explicit attribute in the source to
select fpxx which would need to be optionally included dependent on assembler
support for .module. (The relaxation would have helped here of course.)
Thanks,
Richard
Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Matthew Fortune matthew.fort...@imgtec.com writes:
I think instead we should have a configuration switch that allows a
particular -mfp option to be inserted alongside -mabi=32 if no explicit
-mfp is given. This is how most --with options work. Maybe --with-fp-
32={32|64|xx}? Specific triples could set a default value if they like.
E.g. the MTI, SDE and mipsisa* ones would probably want to default to --
with-32-fp=xx. Triples aimed at MIPS IV and below would stay as they
are. (MIPS IV is sometimes used with -mabi=32.)
--with-fp-32 isn't the greatest name but is at least consistent with
--with-arch-32 and -mabi=32. Maybe --with-fp-32=64 is so weird that
breaking consistency is better though.
Tying the use of fpxx by default to a configure time setting is OK with
me. When enabled it would still have to follow the rules as defined in
the design in that it can only apply to architectures that can support
the variant.
Right. It's really equivalent to putting the -mfp on every command line
that doesn't have one.
Currently that means everything but mips1.
Yeah, using -mips1 on a --with-{o}32-fp=xx toolchain would be an error.
I'm not sure this is the same as tying an ABI to an architecture as
both fp32 and fpxx are O32 and link compatible. Perhaps the configure
switch would be --with-o32-fp={32|64|xx}. This shows it is just an O32
related setting.
What I meant is that -march= and -mips shouldn't imply a different
-mfp setting. The -mfp setting should be self-contained and it should
be an error if the architecture isn't compatible.
We might be in violent agreement here :-) Like I say, I was just a
bit worried by the earlier -mips32r2 thing because there was a time
when a -mips option really could imply things like -mabi, -mgp and -mfp.
--with-o32-fp would be OK with me. I'm just worried about the ABI
being spelt differently from -mabi=, but there's probably no perfect
alternative.
Currently newlib's implementation is assembly code with no
.gnu_attributes. Under the rules above this would start to be
implicitly tagged as gnu_attribute 4,1 (fp32). Any thoughts on how we
transition this to fpxx and still have the modules buildable with old
tools as well? I'm not sure if it will be acceptable to say that it
has to be rewritten in C.
If it's assembled as -mfpxx then it'll be implicitly tagged with the new
.gnu_attribute rather than 4,1. If it's not assembled as -mfpxx then
4,1 would be the right choice.
So this would be dependent on the build system ensuring -mfpxx is passed
as appropriate if the toolchain supports it. There is some risk in this
too if the existing code (which I know is not fpxx safe) gets built with
a new toolchain then it will be tagged as fpxx. I wonder if this tells
us that command line options cannot safely set the FP ABI away from the
default. Instead only the .module and .gnu_attribute can set it as only
the source code can know what FP mode it was written for. The change to
your 4 points above would be that the module level setting is not
impacted by the command line -mfp options.
I don't think that's necessary. For one thing, there's always the
problem with unannotated asm code that the command-line options might
be wrong. There's often not much we can do about that. E.g. we have to
assume that code assembled as -mabi=n32 really is n32 code and not n64
code (and produce a 32-bit rather than 64-bit ELF). There's no way of
hedging our bets in that case: we have to pick an ABI.
For another, leaving the attribute as the default 0 makes the object
compatible with everything, so a file assembled with the wrong -mfpyy
could still be linked with other -mfpyy files. I don't think it gives
us anything extra.
The interaction between .module and command-line options should be the
same for all .module/.set options.
Thanks,
Richard
exposed pipeline
For the 4.7 branch I only saw one architecture using exposed pipeline. Is there any documentation on the quality of exposed pipeline support? Does the back-end need to do anything special to deal with jumps and returns from calls? Thanks Shmeel
Re: Request for discussion: Rewrite of inline assembler docs
On 3/3/2014 3:36 AM, Richard Sandiford wrote: dw limegreenso...@yahoo.com writes: On 2/27/2014 11:32 PM, Richard Sandiford wrote: dw limegreenso...@yahoo.com writes: On 2/27/2014 4:11 AM, Richard Sandiford wrote: Andrew Haley a...@redhat.com writes: Over the years there has been a great deal of traffic on these lists caused by misunderstandings of GCC's inline assembler. That's partly because it's inherently tricky, but the existing documentation needs to be improved. dw limegreenso...@yahoo.com has done a fairly thorough reworking of the documentation. I've helped a bit. Section 6.41 of the GCC manual has been rewritten. It has become: 6.41 How to Use Inline Assembly Language in C Code 6.41.1 Basic Asm - Assembler Instructions with No Operands 6.41.2 Extended Asm - Assembler Instructions with C Expression Operands We could simply post the patch to GCC-patches and have at it, but I think it's better to discuss the document here first. You can read it at http://www.LimeGreenSocks.com/gcc/Basic-Asm.html http://www.LimeGreenSocks.com/gcc/Extended-Asm.html http://www.LimeGreenSocks.com/gcc/extend04.zip (contains .texi, .patch, and affected html pages) All comments are very welcome. Thanks for doing this, looks like a big improvement. Thanks, I did my best. I appreciate you taking the time to review them. A couple of comments: The section on basic asms says: Do not expect a sequence of asm statements to remain perfectly consecutive after compilation. To ensure that assembler instructions maintain their order, use a single asm statement containing multiple instructions. Note that GCC's optimizer can move asm statements relative to other code, including across jumps. The maintain their order might be a bit misleading, since volatile asms (including basic asms) must always be executed in the original order. Maybe this was meaning placement/address order instead? This statement is based on this text from the existing docs: Similarly, you can't expect a sequence of volatile |asm| instructions to remain perfectly consecutive. If you want consecutive output, use a single |asm|. I do not dispute what you are saying. I just want to confirm that the existing docs are incorrect before making a change. Also, see Andi's response re -fno-toplevel-reorder. It seems to me that recommending single statement is both the clearest, and the safest approach here. But I'm prepared to change my mind if there is consensus I should. Right. I agree with that part. I just thought that the maintain their order could be misunderstood as meaning execution order, whereas I think both sentences of the original docs were talking about being perfectly consecutive (which to me means there are no other instructions inbetween). Hmm. I'm not seeing the differences here that you do. Well, like you say, things can be moved across branches. So, although this is a very artificial example: asm (x); asm (y); could become: goto bar; foo: asm (y); ... bar: asm (x); goto foo; This has reordered the instructions in the sense that they have a different order in memory. But they are still _executed_ in the same order. Actually reordering the execution would be a serious bug. So I just want to avoid anything that gives the impression that y can be executed before x in this example. I still think: Since the existing docs say GCC's optimizer can move asm statements relative to other code, how would you feel about: Do not expect a sequence of |asm| statements to remain perfectly consecutive after compilation. If you want to stop the compiler from reordering or inserting anything into a sequence of assembler instructions, use a single |asm| statement containing multiple instructions. Note that GCC's optimizer can move |asm| statements relative to other code, including across jumps. ...this gives the impression that we might try to execute volatiles in a different order. Ahh! Ok, I see what you mean. Hmm. Based on the description of no-toplevel-reorder, I assumed that it actually *might* re-order them. So, more like: GCC's optimizer can move asm statements relative to other code, including across jumps. This has implications for code that contains a sequence of asm statements. While the execution order of asm statements will be preserved, do not expect the sequence of asm statements to remain perfectly consecutive in the compiler's output. To ensure that assembler instructions maintain their order, use a single asm statement containing multiple instructions. It might also be worth mentioning that the number of instances of an asm in the output may be different from the input. (Can it increase as well as decrease? I'm not sure off-hand, but probably yes.) So, in the volatile section, how about something like this for decrease: GCC does not delete a volatile |asm| if it is reachable, but may delete it if it can prove that control
[Bug middle-end/60419] [4.8/4.9 Regression] ICE Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60419 --- Comment #3 from Matthias Klose doko at gcc dot gnu.org --- Created attachment 32265 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32265action=edit preprocessed source (armv7)
[Bug lto/60404] [4.9 Regression] wrong code by LTO on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60404 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Mar 5 08:46:31 2014 New Revision: 208340 URL: http://gcc.gnu.org/viewcvs?rev=208340root=gccview=rev Log: PR lto/60404 * cfgexpand.c (expand_used_vars): Do not assume all SSA_NAMEs of PARM/RESULT_DECLs must be coalesced with optimize in_lto_p. * tree-ssa-coalesce.c (coalesce_ssa_name): Use MUST_COALESCE_COST - 1 cost for in_lto_p. * gcc.dg/lto/pr60404_0.c: New test. * gcc.dg/lto/pr60404_1.c: New file. * gcc.dg/lto/pr60404_2.c: New file. Added: trunk/gcc/testsuite/gcc.dg/lto/pr60404_0.c trunk/gcc/testsuite/gcc.dg/lto/pr60404_1.c trunk/gcc/testsuite/gcc.dg/lto/pr60404_2.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-coalesce.c
[Bug debug/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Note I've posted a patch in the mean time: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00142.html
[Bug lto/60404] [4.9 Regression] wrong code by LTO on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60404 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed, thanks for reporting this.
[Bug target/58595] internal compiler error: in gen_movsi when compiling on arm some files of lttng-tools with -fPIE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58595 --- Comment #13 from ktkachov at gcc dot gnu.org --- This patch bootstrapped on a Chromebook and passed regtest fine for me.
[Bug middle-end/60419] [4.8/4.9 Regression] ICE Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60419 --- Comment #4 from Yury Gribov y.gribov at samsung dot com --- This might have been fixed in trunk already, at least I can't repro for arm-v7a15. My fresh gcc is configured with ~/src/gcc-master/configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=arm-v7a15-linux-gnueabi --prefix=/home/ygribov/install/gcc-master-arm-full --with-sysroot=/home/ygribov/install/gcc-master-arm-full/arm-v7a15-linux-gnueabi/sys-root/ --disable-libmudflap --disable-libssp --disable-nls --disable-libstdcxx-pch --with-interwork --with-mode=arm --with-fpu=vfpv3 --with-cpu=cortex-a15 --with-tune=cortex-a15 --with-float=softfp --enable-libgomp --enable-poison-system-directories --enable-long-long --enable-threads --enable-languages=c,c++ --enable-shared --with-gnu-as --with-gnu-ld --with-build-time-tools=/home/ygribov/install/gcc-master-arm-full --enable-checking CFLAGS='-g -O0' CXXFLAGS='-g -O0'
[Bug c++/60417] [DR 1518] Bogus error on C++03 aggregate initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60417
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org ---
I think Daniel's question is tangential because the testcase can be modified
like so:
B b{};
Or like so:
struct A { explicit A(int = 0); };
struct B { int i; A a; };
int main()
{
B b = { 1 };
}
Now whether B has an explicit default ctor is irrelevant. This bug is about
whether the missing initializer-clause for b.a is equivalent to {} or A{}, and
as I said in PR 60416, [dcl.init.aggr]/7 has an example indicating that the
answer is A{}, so I think the testcase is clearly valid, whatever the
resolution of DR 1518 or Daniel's question.
[Bug libstdc++/60421] New: std::this_thread::sleep_for doesn't sleep for all arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60421
Bug ID: 60421
Summary: std::this_thread::sleep_for doesn't sleep for all
arguments
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jaak at ristioja dot ee
#include chrono
#include limits
#include thread
int main() {
std::this_thread::sleep_for(std::chrono::durationuint64_t(std::numeric_limitsuint64_t::max()));
return 0;
}
This doesn't even sleep a millisecond. Relevant strace output:
nanosleep({18446744073709551615, 0}, NULL) = -1 EINVAL (Invalid argument)
Hence the §30.3.2.7 of the C++11 standard is violated as sleep_for does not
sleep by the relative amount of time specified by its argument. Bug may be run
into during testing.
Also happens with 4.7.3.
[Bug libstdc++/60422] New: bits/xxx.h headers should give a diagnostic when included directly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60422 Bug ID: 60422 Summary: bits/xxx.h headers should give a diagnostic when included directly Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Some users do dumb things like: #include algorithm #include ext/concurrence.h #include bits/unique_ptr.h #include bits/shared_ptr.h and expect to be able to use std::shared_ptr. This happens to work with GCC 4.8, but not with 4.9 because we re-arranged some headers to allow the library to use shared_ptr internally. In order to stop this nonsense we should add preprocessor checks to the headers: #ifndef _MEMORY #error Do not include this header directly, use memory instead #else ... #endif
[Bug middle-end/60419] [4.8/4.9 Regression] ICE Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60419 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.3
[Bug lto/60405] ICE in lto1 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60405 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug middle-end/60418] [4.9 Regression] 435.gromacs in SPEC CPU 2006 is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x32 Target Milestone|--- |4.9.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Hmm, what's the target triplet of a x32-only target?(In reply to H.J. Lu from comment #0) Since r208165, 435.gromacs in SPEC CPU 2006 is miscompiled on x32 with -mx32 -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin The failure is Running 435.gromacs ref peak lto default *** Miscompare of gromacs.out; for details see /export/project/git/gcc-regression/spec/2006/spec/benchspec/CPU2006/435.grom acs/run/run_peak_ref_lto./gromacs.out.mis cat /export/project/git/gcc-regression/spec/2006/spec/benchspec/CPU2006/435. gromacs/run/run_peak_ref_lto./gromacs.out.mis 0002: 3.07684e+02 3.03594e+02 The result of 3.03594e+02 is outside of tolerance for 3.07684e+02. I added a static counter in tree_forwarder_block_p for the number of times returned true above and return false if it is between getenv(from) and getenv(to). I noticed that as more basic blocks get removed, the deviation is getting bigger. One removed basic block has ;; basic block 3, loop depth 0, count 0, freq 225, maybe hot ;; prev block 2, next block 4, flags: (NEW, REACHABLE) ;; pred: 2 ;; ;; succ: 4 and its successor has ;; basic block 4, loop depth 1, count 0, freq 2500, maybe hot ;; prev block 3, next block 5, flags: (NEW) ;; pred: 3 ;; 6 ;; starting at line 722 # gimple_phi i_429, 0(3), [bondfree.c : 726:24] i_27(6) Is is safe to remove basic block 3? Sure it is. This is a loop pre-header.
[Bug middle-end/60418] [4.9 Regression] 435.gromacs in SPEC CPU 2006 is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to H.J. Lu from comment #1) Do we need to verify that basic block DEST has a single predecessor? No, that's not necessary. In fact that disables all pre-header removal (because the loop header always has the loop entry and at least one latch)
[Bug c++/60417] [DR 1518] Bogus error on C++03 aggregate initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60417 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.9.0 |---
[Bug middle-end/60418] [4.9 Regression] 435.gromacs in SPEC CPU 2006 is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to H.J. Lu from comment #0)
Since r208165, 435.gromacs in SPEC CPU 2006 is miscompiled on x32 with
-mx32 -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver
-fuse-linker-plugin
The failure is
Running 435.gromacs ref peak lto default
*** Miscompare of gromacs.out; for details see
/export/project/git/gcc-regression/spec/2006/spec/benchspec/CPU2006/435.grom
acs/run/run_peak_ref_lto./gromacs.out.mis
cat
/export/project/git/gcc-regression/spec/2006/spec/benchspec/CPU2006/435.
gromacs/run/run_peak_ref_lto./gromacs.out.mis
0002: 3.07684e+02
3.03594e+02
The result of 3.03594e+02 is outside of tolerance for 3.07684e+02.
I added a static counter in tree_forwarder_block_p for the number of
times returned true above and return false if it is between getenv(from)
and getenv(to). I noticed that as more basic blocks get removed,
the deviation is getting bigger. One removed basic block has
That's odd. What's the code generation difference in the end
for the minimal range {to, from} that still shows a difference
of the result?
[Bug libstdc++/60422] bits/xxx.h headers should give a diagnostic when included directly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60422 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- #ifndef _GLIBCXX_MEMORY probably (but, as bits/shared_ptr.h is used also in other headers as implementation detail, you'd probably also need to list those guards in the preprocessor conditional).
[Bug plugins/59335] Plugin doesn't build on trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Mar 5 09:52:18 2014 New Revision: 208344 URL: http://gcc.gnu.org/viewcvs?rev=208344root=gccview=rev Log: PR plugins/59335 * config/i386/t-i386 (OPTIONS_H_EXTRA): Add stringop.def. (TM_H): Add x86-tune.def. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/t-i386
[Bug libstdc++/60421] std::this_thread::sleep_for doesn't sleep for all arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60421 Dennis Lubert plasmahh at gmx dot net changed: What|Removed |Added CC||plasmahh at gmx dot net --- Comment #1 from Dennis Lubert plasmahh at gmx dot net --- Note that for me to reproduce this, _GLIBCXX_USE_NANOSLEEP must be defined. In that case it uses directly the nanosleep call, casting the uint64max value to time_t which is signed (which is unfortunately not visible in strace), gets negative and this is what the nonsleep manpage says for glibc: EINVAL The value in the tv_nsec field was not in the range 0 to 9 or tv_sec was negative.
[Bug c++/60423] New: g++ can treat a dynamic POD variable as an array without warning/error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60423
Bug ID: 60423
Summary: g++ can treat a dynamic POD variable as an array
without warning/error
Product: gcc
Version: trans-mem
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: peter.bocan at azet dot sk
Hello guys, we had at university this issue: compiling the code below, throws
no error messages whatsoever, but the code is, as you know, not working. It's,
at least for me, that compiler would recognize this type of mistakes and so it
would be kinda nice to have some type checking upon POD types.
The code is:
int main()
{
int* pod_type = new int(23);
for (int i = 0; i 1; i++)
pot_type[i] = 0xDEADC0DE;
delete pod_type;
return 0;
}
Thank you.
[Bug c++/60423] g++ can treat a dynamic POD variable as an array without warning/error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60423 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- gcc detects this with -fsanitize=address, or -fmudflap, or if you run the program under valgrind.
[Bug lto/60424] New: [4.9 regression] FAIL: gcc.dg/lto/20110201-1 c_lto_20110201-1_0.o-c_lto_20110201-1_0.o link, -O0 -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60424 Bug ID: 60424 Summary: [4.9 regression] FAIL: gcc.dg/lto/20110201-1 c_lto_20110201-1_0.o-c_lto_20110201-1_0.o link, -O0 -flto Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org $ gcc/xgcc -Bgcc/ -O0 -flto -c -o c_lto_20110201-1_0.o ../gcc/testsuite/gcc.dg/lto/20110201-1_0.c $ gcc/xgcc -Bgcc/ c_lto_20110201-1_0.o -O0 -flto -ffast-math -fuse-linker-plugin -o gcc-dg-lto-20110201-1-01.exe /tmp/ccGQ0Up1.ltrans0.ltrans.o: In function `foo': ccGQ0Up1.ltrans0.o:(.text+0x3c): undefined reference to `cabs'
[Bug lto/60424] [4.9 regression] FAIL: gcc.dg/lto/20110201-1 c_lto_20110201-1_0.o-c_lto_20110201-1_0.o link, -O0 -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60424 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug lto/60424] [4.9 regression] FAIL: gcc.dg/lto/20110201-1 c_lto_20110201-1_0.o-c_lto_20110201-1_0.o link, -O0 -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60424 --- Comment #1 from Andreas Schwab sch...@linux-m68k.org --- Started to fail between r208309 and r208316.
[Bug c/60425] New: -fopenmp fails when gcc is compiled to /usr/local
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60425
Bug ID: 60425
Summary: -fopenmp fails when gcc is compiled to /usr/local
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: j-frankish at slb dot com
Using gcc-4.7.2 compiled to /usr/local.
The following fails:
echo int main(){} hello.c
gcc hello.c -fopenmp
..with a message that libgomp.spec cannot be found
editing the output of gcc -dumpspecs:
include(libgomp.spec) - include(/usr/local/lib/libgomp.spec)
include(libitm.spec) - include(/usr/local/lib/libitm.spec)
fixes the error, but shouldn't be required.
[Bug libstdc++/60421] std::this_thread::sleep_for doesn't sleep for all arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60421 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- should probably be fixed along with PR 58038
[Bug middle-end/60426] New: [4.9 Regression] ICE near expand_builtin_int_roundingfn_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60426 Bug ID: 60426 Summary: [4.9 Regression] ICE near expand_builtin_int_roundingfn_2 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch Between r208300 and r208339 LTO compiles of cp2k start failing with the backtrace below. This happens for several files, all traces lead to a NINT in the code. /data/vjoost/gnu/cp2k/cp2k/makefiles/../src/qs_scf_post_gpw.F:977:0: internal compiler error: Segmentation fault nmoloc(ispin) = NINT(nelectron/occupation(1)) ^ 0x9056cf crash_signal ../../gcc/gcc/toplev.c:337 0x57808b contains_struct_check ../../gcc/gcc/tree.h:2822 0x57808b build_call_nofold_loc ../../gcc/gcc/builtins.c:2695 0x580aa5 expand_builtin_int_roundingfn_2 ../../gcc/gcc/builtins.c:2933 0x5a0ae0 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int) ../../gcc/gcc/builtins.c:5928 0x68da35 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/gcc/expr.c:10341 0x6991df store_expr(tree_node*, rtx_def*, int, bool) ../../gcc/gcc/expr.c:5337 0x69bf69 expand_assignment(tree_node*, tree_node*, bool) ../../gcc/gcc/expr.c:5123 0x5bf2ea expand_call_stmt ../../gcc/gcc/cfgexpand.c:2257 0x5bf2ea expand_gimple_stmt_1 ../../gcc/gcc/cfgexpand.c:3158 0x5bf2ea expand_gimple_stmt ../../gcc/gcc/cfgexpand.c:3310 0x5c0957 expand_gimple_basic_block ../../gcc/gcc/cfgexpand.c:5150 0x5c31f9 gimple_expand_cfg ../../gcc/gcc/cfgexpand.c:5729 0x5c31f9 execute ../../gcc/gcc/cfgexpand.c:5949 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [/tmp/ccvOjlYd.ltrans24.ltrans.o] Error 1
[Bug c/60425] -fopenmp fails when gcc is compiled to /usr/local
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60425 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Works just fine here. Can you strace gcc hello.c -fopenmp 21 | grep libgomp.spec ?
[Bug middle-end/60426] [4.9 Regression] ICE near expand_builtin_int_roundingfn_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60426 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- testcase: cat test.f90 SUBROUTINE S1(a,b,N) REAL*8 :: a,b INTEGER :: N N=NINT(a/b) END SUBROUTINE CALL S1(1.0D0,2.0D0,i) END gfortran -flto test.f90 test.f90: In function ‘s1’: test.f90:4:0: internal compiler error: Segmentation fault N=NINT(a/b) ^ 0x9056cf crash_signal ../../gcc/gcc/toplev.c:337
[Bug lto/60427] New: [4.9 Regression] r208312 causes ICE and wrong code for Fortran with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60427 Bug ID: 60427 Summary: [4.9 Regression] r208312 causes ICE and wrong code for Fortran with -flto Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: pmatos at gcc dot gnu.org, rguenth at gcc dot gnu.org After r208312 (+ the fix in r208315) I get FAIL: gfortran.dg/pr33794.f90 -g -flto execution test with both -m32/-m64, and FAIL: gfortran.dg/nint_2.f90 -g -flto (internal compiler error) with -m64 (r208311 + the fix in r208315 is OK). The ICE occurs for the following reduced test real(kind=8) :: a integer(kind=8) :: i1 ! a = nearest(0.5_8,-1.0_8) ! i1 = nint(a) a = 0.5_8 i1 = nint(a) ! a = nearest(0.5_8,1.0_8) ! i1 = nint(a) end [Book15] f90/bug% /opt/gcc/gcc4.9p-208312/bin/gfortran -flto nint_2_red.f90 nint_2_red.f90: In function 'MAIN__': nint_2_red.f90:8:0: internal compiler error: Segmentation fault: 11 i1 = nint(a) The wong code is produced with '-O1 -ffast-math -flto' for gfortran.dg/pr33794.f90 as well as the polyhedron test fatigue.f90.
[Bug middle-end/60426] [4.9 Regression] ICE near expand_builtin_int_roundingfn_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60426 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-05 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Likely a duplicate of pr60427.
[Bug target/60428] New: non-exception (e.g. C) ARM Linux programs depend on libgcc_s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60428 Bug ID: 60428 Summary: non-exception (e.g. C) ARM Linux programs depend on libgcc_s Product: gcc Version: 4.5.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ossman at cendio dot se When compiling a C program for ARM Linux, you can easily end up with dependencies on libgcc_s. This is very annoying as it is not how other targets behave and it means extra work to make binaries that work on a lot of system. I tried to understand the issue, and from what I gather the ARM EABI has a more advanced stack unwinding system that involves calling functions. This combined with helpers in libgcc.a for U64 division that can throw exceptions, results in a dependency on libgcc_s. First question: Why are these libgcc.a functions being built with unwind tables? The stated reason is because of CPU exceptions, but AFAIK those result in signals, not language level exceptions? Second question: Let's assume libgcc.a truly needs the unwinding, or if nothing else there will be other C code that is compiled with -fexceptions for compatibility; can we remove the hard NEEDED for libgcc_s and only use it if some C++ (or similar) code pulls it in? I think the answer to the second question is yes. We've applied the attached patch to our gcc and it seems to do the trick. C code will not have libgcc_s as NEEDED, yet you can still throw exceptions just fine, even across C code compiled with -fexceptions. I am a bit concerned about the interaction of weak symbols in a static library (libgcc.a) and versioned symbols in a proper library (libgcc_s.so). Comments?
[Bug target/60428] non-exception (e.g. C) ARM Linux programs depend on libgcc_s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60428 --- Comment #1 from Pierre Ossman ossman at cendio dot se --- Created attachment 32266 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32266action=edit patch to weaken unwind symbols
[Bug lto/60427] [4.9 Regression] r208312 causes ICE and wrong code for Fortran with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60427 --- Comment #1 from rguenther at suse dot de rguenther at suse dot de --- On Wed, 5 Mar 2014, dominiq at lps dot ens.fr wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60427 Bug ID: 60427 Summary: [4.9 Regression] r208312 causes ICE and wrong code for Fortran with -flto Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: pmatos at gcc dot gnu.org, rguenth at gcc dot gnu.org After r208312 (+ the fix in r208315) I get FAIL: gfortran.dg/pr33794.f90 -g -flto execution test with both -m32/-m64, and FAIL: gfortran.dg/nint_2.f90 -g -flto (internal compiler error) with -m64 (r208311 + the fix in r208315 is OK). The ICE occurs for the following reduced test real(kind=8) :: a integer(kind=8) :: i1 ! a = nearest(0.5_8,-1.0_8) ! i1 = nint(a) a = 0.5_8 i1 = nint(a) ! a = nearest(0.5_8,1.0_8) ! i1 = nint(a) end [Book15] f90/bug% /opt/gcc/gcc4.9p-208312/bin/gfortran -flto nint_2_red.f90 nint_2_red.f90: In function 'MAIN__': nint_2_red.f90:8:0: internal compiler error: Segmentation fault: 11 i1 = nint(a) The wong code is produced with '-O1 -ffast-math -flto' for gfortran.dg/pr33794.f90 as well as the polyhedron test fatigue.f90. Hmm, this is because mathfn_built_in_1 does if (TYPE_MAIN_VARIANT (type) == double_type_node) fcode2 = fcode; else if (TYPE_MAIN_VARIANT (type) == float_type_node) fcode2 = fcodef; else if (TYPE_MAIN_VARIANT (type) == long_double_type_node) fcode2 = fcodel; else return NULL_TREE; and we now have two double_type_nodes (the global tree built by lto1 and the one that is now streamed literally). IMHO we want to revert the patch at this point.
[Bug target/60428] non-exception (e.g. C) ARM Linux programs depend on libgcc_s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60428 --- Comment #2 from Pierre Ossman ossman at cendio dot se --- Created attachment 32267 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32267action=edit test case
[Bug lto/60427] [4.9 Regression] r208312 causes ICE and wrong code for Fortran with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60427 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- *** Bug 60426 has been marked as a duplicate of this bug. ***
[Bug middle-end/60426] [4.9 Regression] ICE near expand_builtin_int_roundingfn_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60426 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- yes, dup for sure *** This bug has been marked as a duplicate of bug 60427 ***
[Bug c/60425] -fopenmp fails when gcc is compiled to /usr/local
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60425 --- Comment #2 from j-frankish at slb dot com --- Ah - I see the problem now. I'm using gcc packaged into a squashfs package, loop mounted at /tmp/tcloop/gcc and symlinked to the root file system. The gcc libs are packaged separately and mounted at /tmp/tcloop/gcc_libs. As -fopenmp is searching a relative path to libgomp.spec and only looks in absolute paths to /lib and /usr/lib, it does not find it. I entered the absolute path /usr/local/lib/libgomp.spec in the root file system in the specs file, which is what made things work. ..in some respects, if gcc is compiled to /usr/local, shouldn't it search the absolute path to /usr/local? -- $ strace gcc hello.c -fopenmp 21 | grep libgomp.spec strace gcc hello.c -fopenmp 21 | grep libgomp.spec access(/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/4.7.2/libgomp.spec, R_OK) = -1 ENOENT (No such file or directory) access(/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/libgomp.spec, R_OK) = -1 ENOENT (No such file or directory) access(/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/4.7.2/../../../../i486-pc-linux-gnu/lib/i486-pc-linux-gnu/4.7.2/libgomp.spec, R_OK) = -1 ENOENT (No such file or directory) access(/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/4.7.2/../../../../i486-pc-linux-gnu/lib/libgomp.spec, R_OK) = -1 ENOENT (No such file or directory) access(/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/4.7.2/../../../i486-pc-linux-gnu/4.7.2/libgomp.spec, R_OK) = -1 ENOENT (No such file or directory) access(/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/4.7.2/../../../libgomp.spec, R_OK) = -1 ENOENT (No such file or directory) access(/lib/i486-pc-linux-gnu/4.7.2/libgomp.spec, R_OK) = -1 ENOENT (No such file or directory) access(/lib/libgomp.spec, R_OK) = -1 ENOENT (No such file or directory) access(/usr/lib/i486-pc-linux-gnu/4.7.2/libgomp.spec, R_OK) = -1 ENOENT (No such file or directory) access(/usr/lib/libgomp.spec, R_OK) = -1 ENOENT (No such file or directory) open(libgomp.spec, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) write(2, gcc: error: libgomp.spec: No suc..., 51gcc: error: libgomp.spec: No such file or directory) = 51
[Bug c/60425] -fopenmp fails when gcc is compiled to /usr/local
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60425 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- User problem then.
[Bug libgcc/60429] New: Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 Bug ID: 60429 Summary: Miscompilation (aliasing) with -finline-functions Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: linux at carewolf dot com After recently trying to build Qt with -O3, I found one of our tests failing. After investigating I narrowed it down to qregion.cpp and the flag -finline-functions (using -O2 -finline-functions). Specificially the inlining of the function loadAET() in QRegionPrivate *PolygonRegion() causes the problem. Adding __attribute__((noinline)) to loadAET() solves the problem. Interestingly compiling without -finline-function and just marking the loadAET as inline or always_inline, does not trigger the issue. The code is not Qt specific and is used in a other projects, though it is most places compiled as C code. Further testing shows the issue is also triggered in GCC 4.6, 4.7, and the latest version of 4.9 I had. It is however NOT present in GCC 4.4, so this is a regression. Looking at the assembler and debug output, I believe the that the variable pAET that should have been reloaded after loadAET() has been eliminated. This might be what breaks the aliasing rules.
[Bug libgcc/60429] Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 --- Comment #1 from Allan Jensen linux at carewolf dot com --- Created attachment 32268 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32268action=edit qregion.cpp intermediate compiled with G++ 4.4 (working)
[Bug libgcc/60429] Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 --- Comment #2 from Allan Jensen linux at carewolf dot com --- Created attachment 32269 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32269action=edit qregion.cpp intermediate compiled with gcc 4.8
[Bug libgcc/60429] Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 --- Comment #3 from Allan Jensen linux at carewolf dot com --- Created attachment 32270 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32270action=edit qregion.cpp assembler compiled with gcc 4.8
[Bug libgcc/60429] Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 --- Comment #4 from Allan Jensen linux at carewolf dot com --- Created attachment 32271 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32271action=edit qregion.cpp assembler compiled with gcc 4.4
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 --- Comment #22 from David Kredba nheghathivhistha at gmail dot com --- I got this now with rev. 208241: /usr/bin/x86_64-pc-linux-gnu-g++ -fPIC -O2 -ggdb -pipe -march=native -mtune=native -mno-3dnow -mno-sse4.2 -mno-avx -Wnon-virtual-dtor -Wno-long-long -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS -fno-check-new -fno-common -Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden -fvisibility-inlines-hidden -fexceptions -UQT_NO_EXCEPTIONS -Wl,--enable-new-dtags -Wl,--no-undefined -lc -Wl,--as-needed -Wl,-O2 -O2 -ggdb -pipe -march=native -mtune=native -shared -Wl,-soname,libkorganizer_core.so.4 -o ../lib/libkorganizer_core.so.4.12.3 CMakeFiles/korganizer_core.dir/korganizer_core_automoc.o CMakeFiles/korganizer_core.dir/koprefs.o CMakeFiles/korganizer_core.dir/kocore.o CMakeFiles/korganizer_core.dir/koprefs_base.o -L/var/tmp/portage/kde-base/korganizer-4.12.3/work/korganizer-4.12.3_build/lib -L/usr/lib64/qt4 ../lib/libcalendarsupport.so.4.12.3 -leventviews ../lib/libincidenceeditorsng.so.4.12.3 -lkdepim ../lib/libkorganizer_interfaces.so.4.12.3 /usr/lib64/libakonadi-kde.so.4.12.3 /usr/lib64/libkcalcore.so.4.12.3 /usr/lib64/libkcalutils.so.4.12.3 /usr/lib64/libkmime.so.4.12.3 /usr/lib64/libkpimidentities.so.4.12.3 /usr/lib64/libkdecore.so.5.12.3 /usr/lib64/libkio.so.5.12.3 /usr/lib64/qt4/libQtUiTools.a -lz -lkdepim /usr/lib64/libkldap.so.4.12.3 /usr/lib64/libkcmutils.so.4.12.3 -lkdgantt2 -lakonadi_next -lakonadi-calendar ../lib/libcalendarsupport.so.4.12.3 /usr/lib64/libkcalutils.so.4.12.3 /usr/lib64/libkpimidentities.so.4.12.3 /usr/lib64/libkpimtextedit.so.4.12.3 /usr/lib64/libkholidays.so.4.12.3 /usr/lib64/libakonadi-contact.so.4.12.3 /usr/lib64/libkcalcore.so.4.12.3 /usr/lib64/libkabc.so.4.12.3 /usr/lib64/libkresources.so.4.12.3 /usr/lib64/libkpimutils.so.4.12.3 /usr/lib64/libnepomukcore.so.4.12.3 -lphonon /usr/lib64/libkmime.so.4.12.3 /usr/lib64/libakonadi-kde.so.4.12.3 /usr/lib64/libakonadiprotocolinternals.so.1.11.0 /usr/lib64/libkio.so.5.12.3 /usr/lib64/libsolid.so.4.12.3 /usr/lib64/qt4/libQtNetwork.so /usr/lib64/qt4/libQtXml.so /usr/lib64/libkdeui.so.5.12.3 /usr/lib64/libkdecore.so.5.12.3 /usr/lib64/qt4/libQtCore.so -lpthread /usr/lib64/qt4/libQtDBus.so /usr/lib64/qt4/libQtGui.so /usr/lib64/qt4/libQtSvg.so -lsoprano -Wl,-rpath,/var/tmp/portage/kde-base/korganizer-4.12.3/work/korganizer-4.12.3_build/lib:/usr/lib64/qt4: CMakeFiles/korganizer_core.dir/kocore.o: In function `~Part': /var/tmp/portage/kde-base/korganizer-4.12.3/work/korganizer-4.12.3/korganizer/interfaces/korganizer/part.h:55: undefined reference to `KParts::Part::~Part()' CMakeFiles/korganizer_core.dir/kocore.o: In function `KOrg::Part::~Part()': /var/tmp/portage/kde-base/korganizer-4.12.3/work/korganizer-4.12.3/korganizer/interfaces/korganizer/part.h:55: undefined reference to `KParts::Part::~Part()' CMakeFiles/korganizer_core.dir/kocore.o: In function `~Part': /var/tmp/portage/kde-base/korganizer-4.12.3/work/korganizer-4.12.3/korganizer/interfaces/korganizer/part.h:55: undefined reference to `KParts::Part::~Part()' CMakeFiles/korganizer_core.dir/kocore.o:(.data.rel.ro._ZTIN4KOrg4PartE[_ZTIN4KOrg4PartE]+0x10): undefined reference to `typeinfo for KParts::Part' CMakeFiles/korganizer_core.dir/kocore.o:(.data.rel.ro._ZTCN4KOrg4PartE16_N6KParts8PartBaseE[_ZTVN4KOrg4PartE]+0x10): undefined reference to `typeinfo for KParts::PartBase' CMakeFiles/korganizer_core.dir/kocore.o:(.data.rel.ro._ZTCN4KOrg4PartE16_N6KParts8PartBaseE[_ZTVN4KOrg4PartE]+0x18): undefined reference to `KParts::PartBase::~PartBase()' CMakeFiles/korganizer_core.dir/kocore.o:(.data.rel.ro._ZTCN4KOrg4PartE16_N6KParts8PartBaseE[_ZTVN4KOrg4PartE]+0x20): undefined reference to `KParts::PartBase::~PartBase()' CMakeFiles/korganizer_core.dir/kocore.o:(.data.rel.ro._ZTCN4KOrg4PartE16_N6KParts8PartBaseE[_ZTVN4KOrg4PartE]+0x28): undefined reference to `KParts::PartBase::setComponentData(KComponentData const)' CMakeFiles/korganizer_core.dir/kocore.o:(.data.rel.ro._ZTCN4KOrg4PartE16_N6KParts8PartBaseE[_ZTVN4KOrg4PartE]+0x30): undefined reference to `KParts::PartBase::setComponentData(KComponentData const, bool)' CMakeFiles/korganizer_core.dir/kocore.o:(.data.rel.ro._ZTCN4KOrg4PartE16_N6KParts8PartBaseE[_ZTVN4KOrg4PartE]+0xb0): undefined reference to `typeinfo for KParts::PartBase' CMakeFiles/korganizer_core.dir/kocore.o:(.data.rel.ro._ZTCN4KOrg4PartE16_N6KParts8PartBaseE[_ZTVN4KOrg4PartE]+0xb8): undefined reference to `virtual thunk to KParts::PartBase::~PartBase()' CMakeFiles/korganizer_core.dir/kocore.o:(.data.rel.ro._ZTCN4KOrg4PartE16_N6KParts8PartBaseE[_ZTVN4KOrg4PartE]+0xc0): undefined reference to `virtual thunk to KParts::PartBase::~PartBase()' CMakeFiles/korganizer_core.dir/kocore.o:(.data.rel.ro._ZTCN4KOrg4PartE16_N6KParts8PartBaseE[_ZTVN4KOrg4PartE]+0xf8): undefined reference to `virtual thunk to
[Bug target/57631] Use assembler name for sanity checking of ISR names provided it is set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57631 Michal Hlavinka mhlavink at redhat dot com changed: What|Removed |Added CC||mhlavink at redhat dot com --- Comment #14 from Michal Hlavinka mhlavink at redhat dot com --- This causes regression: protocols/pulses_avr.cpp:104:1: warning: '_vector_12' appears to be a misspelled signal handler [enabled by default] ISR(TIMER1_COMPA_vect) //2MHz pulse generation (BLOCKING ISR) ^ the +1 in the fix(gcc/config/avr/avr.c): name = DECL_ASSEMBLER_NAME_SET_P (decl) /* Remove the leading '*' added in set_user_assembler_name. */ ? 1 + IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl)) : IDENTIFIER_POINTER (DECL_NAME (decl)); makes name == _vector_12 instead of __vector_12 and it triggers warning a few lines later tested version: gcc-4.8.2
[Bug c++/60409] [4.9 Regression] [c++1y] ICE on valid with template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60409 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r197248.
[Bug fortran/58880] [4.9 Regression] [OOP] ICE on valid with FINAL function and type extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58880 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #3) I guess it's fair to say that the ICE is technically a regression. So it is a real regression within 4.9.0. Well, one can argue whether a bug in a new feature is a real regression ...
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #23 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Is this a new re-occurence?
Looks likely:
markus@x4 tmp % test.ii
template typename T class A
{
public:
A (T );
typename T::const_iterator i;
};
template typename T class B
{
public:
class const_iterator
{
public:
T operator*();
};
};
namespace KParts
{
class PartBase
{
public:
virtual ~PartBase ();
};
class Part : PartBase
{
};
}
class Part : KParts::Part
{
public:
typedef BPart * List;
~Part () {}
};
void fn1 (Part::List p1)
{
for (A__typeof__ p1 a (p1);;)
for (Part *b = *a.i;;)
delete b;
}
markus@x4 tmp % g++ -Wall -Wextra -c -O2 test.ii
markus@x4 tmp % nm test.o | c++filt
T fn1(BPart*)
U operator delete(void*)
U ABPart* ::A(BPart*)
U BPart*::const_iterator::operator*()
W Part::~Part()
W Part::~Part()
W Part::~Part()
n Part::~Part()
W KParts::Part::~Part()
W KParts::Part::~Part()
W KParts::Part::~Part()
n KParts::Part::~Part()
U KParts::PartBase::~PartBase()
V typeinfo for KParts::Part
U typeinfo for KParts::PartBase
V typeinfo name for KParts::Part
U vtable for __cxxabiv1::__vmi_class_type_info
V vtable for KParts::Part
markus@x4 tmp % /usr/x86_64-pc-linux-gnu/gcc-bin/4.8.3/g++ -Wall -Wextra -c -O2
test.ii
markus@x4 tmp % nm test.o | c++filt
T fn1(BPart*)
U ABPart* ::A(BPart*)
U BPart*::const_iterator::operator*()
markus@x4 tmp %
[Bug plugins/59335] Plugin doesn't build on trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335 --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Mar 5 15:06:23 2014 New Revision: 208346 URL: http://gcc.gnu.org/viewcvs?rev=208346root=gccview=rev Log: PR plugins/59335 * Makefile.in (PLUGIN_HEADERS): Add tree-phinodes.h, stor-layout.h, ssa-iterators.h, $(RESOURCE_H) and tree-cfgcleanup.h. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 --- Comment #24 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Created attachment 32272 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32272action=edit Unreduced testcase Here's the unreduced testcase: markus@x4 tmp % g++ -Wall -Wextra -c -O2 test.ii markus@x4 tmp % nm test.o | c++filt | grep KPart U KParts::Part::setManager(KParts::PartManager*) U KParts::Part::customEvent(QEvent*) U KParts::Part::qt_metacall(QMetaObject::Call, int, void**) U KParts::Part::qt_metacast(char const*) U KParts::Part::setSelectable(bool) U KParts::Part::partSelectEvent(KParts::PartSelectEvent*) U KParts::Part::guiActivateEvent(KParts::GUIActivateEvent*) U KParts::Part::partActivateEvent(KParts::PartActivateEvent*) U KParts::Part::embed(QWidget*) U KParts::Part::widget() U KParts::Part::hitTest(QWidget*, QPoint const) U KParts::Part::setWidget(QWidget*) U KParts::Part::~Part() U KParts::Part::~Part() U KParts::Part::~Part() U KParts::PartBase::setComponentData(KComponentData const) U KParts::PartBase::setComponentData(KComponentData const, bool) U KParts::PartBase::~PartBase() U KParts::PartBase::~PartBase() U KParts::Part::metaObject() const V construction vtable for KParts::Part-in-KOrg::Part V construction vtable for KParts::PartBase-in-KOrg::Part U non-virtual thunk to KParts::Part::~Part() U non-virtual thunk to KParts::Part::~Part() U typeinfo for KParts::Part U typeinfo for KParts::PartBase U virtual thunk to KParts::Part::~Part() U virtual thunk to KParts::Part::~Part() U virtual thunk to KParts::PartBase::~PartBase() U virtual thunk to KParts::PartBase::~PartBase() U virtual thunk to KParts::PartBase::setComponentData(KComponentData const)
[Bug target/60369] [PATCH] [TIC6X] new compiler intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60369 --- Comment #1 from Wojciech Migda wojtek.golf at interia dot pl --- Created attachment 32273 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32273action=edit Patch, as specified in the report body.
[Bug fortran/58880] [4.9 Regression] [OOP] ICE on valid with FINAL function and type extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58880 --- Comment #6 from janus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #5) Well, one can argue whether a bug in a new feature is a real regression ... Yeah, but maybe we should rather argue about how to fix it than how to classify it ;)
[Bug lto/60427] [4.9 Regression] r208312 causes ICE and wrong code for Fortran with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60427 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.9.0
[Bug lto/60424] [4.9 regression] FAIL: gcc.dg/lto/20110201-1 c_lto_20110201-1_0.o-c_lto_20110201-1_0.o link, -O0 -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60424 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Which architecture?
[Bug lto/60424] [4.9 regression] FAIL: gcc.dg/lto/20110201-1 c_lto_20110201-1_0.o-c_lto_20110201-1_0.o link, -O0 -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60424 --- Comment #3 from Andreas Schwab sch...@linux-m68k.org --- Everywhere.
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 --- Comment #25 from Jason Merrill jason at gcc dot gnu.org --- OK, this testcase wasn't affected by my earlier patch because ~Part is user-defined, so it's fair game for devirtualization. I notice, however, that in the unreduced testcase Part is an abstract class, so it doesn't make sense to choose its destructor for speculative devirtualization: that can never be the right answer. I'll fix that.
[Bug debug/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381 --- Comment #6 from Alexandre Oliva aoliva at gcc dot gnu.org --- Created attachment 32274 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32274action=edit WIP patch to start combining useless value removal and table reset, after reverting the faulty patch I'd prefer if we kept the preserved table without potentially useless locs. I've struggled for several hours this morning trying to combine useless value removal, preservation of values in the alternate table, detection of constants and equivalences for preservation and discarding values that should not be preserved into fewer passes over the hash table, unfortunately without much success. In the end, I returned to mostly separate removal and reset passes, but I've managed to make both passes optional, except at the end of vt_initialize. Here's the WIP patch, to be applied after the reversal of the faulty patch. Unfortunately, the result is not much faster than the reversal, probably because it works much harder to release cselib_vals and loc lists as they get removed from the table, instead of just dropping them on the floor till the pool is released as a whole.
[Bug lto/60424] [4.9 regression] FAIL: gcc.dg/lto/20110201-1 c_lto_20110201-1_0.o-c_lto_20110201-1_0.o link, -O0 -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60424 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Isn't this the same issue as PR60427?
[Bug c++/60430] New: static_assert and reference to const/constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60430
Bug ID: 60430
Summary: static_assert and reference to const/constexpr
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: florent.hivert at lri dot fr
I think the following should be accepted:
constexpr const int A = 42;
const int B = A;
static_assert(A == B, Bug);
int main() {return 0;}
Indeed, even if B is not constexpr its address is. On the contrary GCC
complains with
bug2.cpp:3:1: error: non-constant condition for static assertion
static_assert(A == B, Bug);
^
bug2.cpp:3:1: error: the value of ‘B’ is not usable in a constant expression
bug2.cpp:2:12: note: ‘B’ was not declared ‘constexpr’
const int B = A;
[Bug debug/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60381 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- I admit I haven't timed the insn-recog.c compilation time with my patch, but I haven't noticed that the compile time would increase significantly. I guess I can benchmark it now.
[Bug target/60431] [PATCH] [TIC6X] target description missing abssi2 insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60431 --- Comment #1 from Wojciech Migda wojtek.golf at interia dot pl --- Created attachment 32275 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32275action=edit Proposed patch
[Bug target/60431] New: [PATCH] [TIC6X] target description missing abssi2 insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60431
Bug ID: 60431
Summary: [PATCH] [TIC6X] target description missing abssi2 insn
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wojtek.golf at interia dot pl
Host: Linux wmigda-desktop 3.11.0-13-generic #20-Ubuntu SMP
Wed Oct 23 17:26:33 UTC 2013 i686 i686 i686 GNU/Linux
Target: tic6x-none-elf
Build: tic6x-none-elf-gcc-4.8.3 (GCC) 4.8.3 20140303
(prerelease)
Target definition has ssabssi2 insn definition, which uses ss_abs operand, but
does not have an insn which uses abs operand. As a result simple code which one
would expect to generate abs insn generates much less efficient set of
expressions.
For the testcase:
# 1 main.c
# 1 command-line
# 1 main.c
int fn_1(int x)
{
return (x = 0) ? x : -x;
}
int fn_2(int x)
{
return (x 0) ? x : -x;
}
stock gcc generates (-march=c674x -fverbose-asm -O2 -g0 -S -dp main.c
-fdump-final-insns=rtl-dump.rtl):
(insn# 0 0 2 (sequence [
(insn:TI# # # 2 (unspec [
(reg:SI 35 B3)
(const_int 2 [0x2])
] UNSPEC_REAL_JUMP) main.c:4# {real_ret}
(nil))
(insn# # # 2 (set (reg:SI 3 A3 [77])
(ashiftrt:SI (reg/v:SI 4 A4 [orig:75 x ] [75])
(const_int 31 [0x1f]))) main.c:4# {ashrsi3}
(nil))
]) main.c:4#
(nil))
(insn:TI# 0 0 2 (set (reg:SI 4 A4 [orig:76 D.1411 ] [76])
(xor:SI (reg:SI 3 A3 [77])
(reg/v:SI 4 A4 [orig:75 x ] [75]))) main.c:3# {xorsi3}
(nil))
(insn:TI# 0 0 2 (set (reg/i:SI 4 A4)
(minus:SI (reg:SI 4 A4 [orig:76 D.1411 ] [76])
(reg:SI 3 A3 [77]))) main.c:4# {subsi3}
(expr_list:REG_DEAD (reg:SI 3 A3 [77])
(nil)))
(insn:TI# 0 0 2 (unspec [
(const_int 3 [0x3])
] UNSPEC_NOP) main.c:4# {nop_count}
(nil))
(insn# 0 0 2 (use (reg/i:SI 4 A4)) main.c:4#
(nil))
(jump_insn:TI# 0 0 2 (parallel [
(unspec [
(const_int 0 [0])
] UNSPEC_JUMP_SHADOW)
(return)
]) main.c:4# {return_shadow}
(expr_list:REG_DEAD (reg:SI 35 B3)
(nil))
- return)
In contrast, Texas Instruments compiler produces the machine code below:
_fn_1:
BNOP.S2 B3,4
ABS.L1A4,A4
_fn_2:
BNOP.S2 B3,3
CMPLT.L1 0,A4,A0
[!A0] NEG.L1A4,A4
The proposed patch introduces a clone of the ssabssi2 insn which uses abs
instead of ss_abs operand.
When it is applied gcc produces rtl below:
(insn# 0 0 2 (sequence [
(insn:TI# # # 2 (unspec [
(reg:SI 35 B3)
(const_int 2 [0x2])
] UNSPEC_REAL_JUMP) main.c:4# {real_ret}
(nil))
(insn# # # 2 (set (reg/i:SI 4 A4)
(abs:SI (reg:SI 4 A4 [ x ]))) main.c:4# {abssi2}
(nil))
]) main.c:4#
(nil))
(insn:TI# 0 0 2 (unspec [
(const_int 5 [0x5])
] UNSPEC_NOP) main.c:4# {nop_count}
(nil))
(insn# 0 0 2 (use (reg/i:SI 4 A4)) main.c:4#
(nil))
(jump_insn:TI# 0 0 2 (parallel [
(unspec [
(const_int 0 [0])
] UNSPEC_JUMP_SHADOW)
(return)
]) main.c:4# {return_shadow}
(expr_list:REG_DEAD (reg:SI 35 B3)
(nil))
- return)
for both functions fn_1 and fn_2 from the testcase listed above. One can notice
that this time abssi2 will be used and that for fn_2 gcc will properly
recognize that it can generate the same rtl as for fn_1, which will be better
than that produced by the TI compiler.
ChangeLog
2014-03-05 Wojciech Migda wojtek.g...@interia.pl
* gcc/config/c6x/c6x.md: abssi2 instruction.
* gcc/testsuite/gcc.target/tic6x/abssi2-scan.c: abssi2 testcases.
Bootstrapping and testing
Host: Linux wmigda-desktop 3.11.0-13-generic #20-Ubuntu SMP Wed Oct 23 17:26:33
UTC 2013 i686 i686 i686 GNU/Linux
Target: tic6x-none-elf
Results for the new testcases (run with make check-gcc
RUNTESTFLAGS=CFLAGS_FOR_TARGET='$CFLAGS_FOR_TARGET
--sysroot=${CXTOOLS}${TRIPLET}/sysroot' -v -v tic6x.exp)
PASS: gcc.target/tic6x/abssi2-scan.c (test for excess errors)
PASS: gcc.target/tic6x/abssi2-scan.c scan-assembler-times [\\t ]abs[\\t ] 2
Patch attached.
[Bug target/60431] [PATCH] [TIC6X] target description missing abssi2 insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60431 --- Comment #2 from Wojciech Migda wojtek.golf at interia dot pl --- Created attachment 32276 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32276action=edit patch amendment - previous was incomplete
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 --- Comment #26 from David Kredba nheghathivhistha at gmail dot com --- Hello Markus, Could you kindly please write here how are you reducing this? (So next time I can try to do it myself.) Thank you in advance.
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 --- Comment #27 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to David Kredba from comment #26) Hello Markus, Could you kindly please write here how are you reducing this? (So next time I can try to do it myself.) Sure. First thing is to find out which object files contains these undefined symbols. cd /var/tmp/portage/kde-base/korganizer-4.12.3 for f in **/*.o ; do echo $f nm $f | c++filt | grep KParts::Part::~Part() ; done This will point to kocore.o. Then lookup how kocore.o was compiled in the build.log. Add --save-temps to the invocation. Write a check.sh script for creduce, e.g. something like: % cat check.sh #!/bin/sh /usr/x86_64-pc-linux-gnu/gcc-bin/4.8.3/g++ -Wall -Wextra -c -O2 -Werror -Wfatal-errors -c test.ii -pipe if ! test $? = 0; then exit 1 fi nm test.o | grep _ZN6KParts4PartD0Ev if test $? = 0; then exit 1 fi g++ -Wall -Wextra -c -O2 -Werror -Wfatal-errors test.ii -pipe if ! test $? = 0; then exit 1 fi nm test.o | grep _ZN6KParts4PartD0Ev if ! test $? = 0; then exit 1 fi And finally run creduce.
[Bug fortran/58842] libgfortran configuration error in 32-bit mode for GCC 4.8 with MacPorts universal installation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58842 --- Comment #4 from Eric Gallager egall at gwmail dot gwu.edu --- (In reply to Eric Gallager from comment #3) I am running into this error as well. I attached my relevant logfiles in the downstream ticket that the OP linked to. (In reply to Dominique d'Humieres from comment #1) Check (1) that you have the right versions of this libraries in /opt/local that pass 'make check' without error; Local-Admins-MacBook-Pro:~ ericgallager$ port installed gmp mpfr libmpc The following ports are currently installed: gmp @5.1.2_0+universal (active) libmpc @1.0.2_0+universal (active) mpfr @3.1.1-p2_0+universal (active) I lost my results for their testsuites, but I suppose that I can run them again... So I am back after re-running the testsuites, and it turned out that mpfr was the culprit, so I opened a separate issue downstream for that: https://trac.macports.org/ticket/42732
[Bug c++/60432] New: Member pointer resolution within class definition causes segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60432 Bug ID: 60432 Summary: Member pointer resolution within class definition causes segmentation fault Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jpelletier at jumptrading dot com
[Bug c++/60432] Member pointer resolution within class definition causes segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60432 --- Comment #1 from jpelletier at jumptrading dot com --- Created attachment 32277 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32277action=edit full error output
[Bug c++/60432] Member pointer resolution within class definition causes segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60432
--- Comment #2 from jpelletier at jumptrading dot com ---
The following code causes a segmentation fault:
#include tuple
struct A
{
int a;
static constexpr int A::*p = A::a;
};
%g++ -std=c++11 -c member.cc
member.cc:6:35: internal compiler error: Segmentation fault
static constexpr int A::*p = A::a;
^
[Bug c++/60432] Member pointer resolution within class definition causes segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60432 --- Comment #3 from jpelletier at jumptrading dot com --- Created attachment 32278 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32278action=edit preprocessed file
[Bug fortran/58842] libgfortran configuration error in 32-bit mode for GCC 4.8 with MacPorts universal installation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58842 --- Comment #5 from Eric Gallager egall at gwmail dot gwu.edu --- (In reply to Eric Gallager from comment #4) I lost my results for their testsuites, but I suppose that I can run them again... So I am back after re-running the testsuites, and it turned out that mpfr was the culprit, so I opened a separate issue downstream for that: https://trac.macports.org/ticket/42732 Actually libmpc was to blame as well: https://trac.macports.org/ticket/42733
[Bug c++/60361] [4.7/4.8/4.9 Regression] unexpected 'use of parameter outside function body' error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60361 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Mar 5 17:53:28 2014 New Revision: 208351 URL: http://gcc.gnu.org/viewcvs?rev=208351root=gccview=rev Log: PR c++/60361 * parser.c (cp_parser_template_id): Don't set up a CPP_TEMPLATE_ID if re-parsing might succeed. * semantics.c (finish_id_expression): Use of a parameter outside the function body is a parse error. Added: trunk/gcc/testsuite/g++.dg/parse/ambig7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/g++.dg/parse/parameter-declaration-2.C trunk/gcc/testsuite/g++.dg/parse/typename7.C
[Bug c++/60409] [4.9 Regression] [c++1y] ICE on valid with template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60409 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/60361] [4.7/4.8 Regression] unexpected 'use of parameter outside function body' error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60361 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.0 Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] |unexpected 'use of |unexpected 'use of |parameter outside function |parameter outside function |body' error |body' error Known to fail|4.9.0 | --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Fixed in 4.9 for now.
[Bug target/60431] [PATCH] [TIC6X] target description missing abssi2 insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60431 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com --- The semantics of the abssi2 insn pattern on the most negative integer are that it returns the argument unchanged (RTL operations are generally modulo; the semantics don't depend on whether -fwrapv is used). Thus, a saturating abs instruction is unsuitable for implementing that pattern; you need to make the machine-independent compiler able to use ssabssi2 to expand ABS_EXPR-with-undefined-overflow (i.e. ABS_EXPR without flag_wrapv or flag_trapv), when the saturating pattern is present but not the non-saturating pattern.
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 --- Comment #28 from Jason Merrill jason at gcc dot gnu.org --- Created attachment 32279 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32279action=edit New patch Does this fix KDE?
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 --- Comment #29 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Jason Merrill from comment #28) Created attachment 32279 [details] New patch Does this fix KDE? Yes. Thanks Jason.
