Re: [analyzer PATCH] Restore bootstrap with g++ 4.8.
On 14/06/24 11:42 +0100, Jonathan Wakely wrote:
On 14/06/24 11:37 +0100, Jonathan Wakely wrote:
On 14/06/24 11:26 +0100, Jonathan Wakely wrote:
On 14/06/24 10:36 +0100, Jonathan Wakely wrote:
On 07/06/24 19:40 +0100, Roger Sayle wrote:
This patch restores bootstrap when using g++ 4.8 as a host compiler.
Returning a std::unique_ptr requires a std::move on C++ compilers
(pre-C++17) that don't guarantee copy elision/return value optimization.
It doesn't though. The C++17 guaranteed copy elision rules are not
relevant here. This is about lookup for the constructor used in the
return statement, and whether that lookup considers the variable to be
an lvalue or an rvalue. C++11 already says this is valid:
i#include
std::unique_ptr f()
{
std::unique_ptr m;
return m;
}
See C++11 12.8 [class.copy] p31:
This elision of copy/move operations, called copy elision, is
permitted in the following circumstances (which may be combined to
eliminate multiple copies):
- in a return statement in a function with a class return type, when
the expression is the name of a non-volatile automatic object (other
than a function or catch-clause parameter) with the same cv-
unqualified type as the function return type, the copy/move
operation can be omitted by constructing the automatic object
directly into the function’s return value
and then p32:
When the criteria for elision of a copy operation are met or would
be met save for the fact that the source object is a function
parameter, and the object to be copied is designated by an lvalue,
overload resolution to select the constructor for the copy is first
performed as if the object were designated by an rvalue.
The constructor isn't required to be elided in C++11, but the compiler
is required to use a move constructor instead of a copy constructor,
if a move constructor is available. So you don't need to use std::move
on the return value.
And the code above compiles fine with gcc 4.8.5 on CentOS 7 (and even
with 4.7.1).
So the std::move calls you've added are redundant, and will cause
-Wredundant-move warnings.
What's the error you were seeing?
I can reproduce it:
/home/test/src/gcc/gcc/analyzer/constraint-manager.cc: In member function
‘std::unique_ptr ana::equiv_class::make_dump_widget(const
text_art::dump_widget_info&, unsigned int) const’:
/home/test/src/gcc/gcc/analyzer/constraint-manager.cc:1179:10: error: cannot bind
‘std::unique_ptr’ lvalue to
‘std::unique_ptr&&’
return ec_widget;
^
Odd ... I'm looking into it ...
Ah, the problem here is that the function's return type is
std::unique_ptr but the return value is
std::unique_ptr and that requires the converting
constructor, not the move constructor.
That *did* change after C++11, and isn't supported by G++ until 5.1
That changed with https://cplusplus.github.io/CWG/issues/1579.html
Which for the record was implemented in r5-1576-gfb682f9458c6cf (by
me, which I'd forgotten!)
which is in C++14 and is a DR against C++11, but of course compilers
that implement the original C++11 rules don't support that DR.
Arguably, g++ should not give -Wredundant-move warnings here when
using the -std=c++11 dialect, because it's only redundant if the C++11
compiler implements that DR.
Is there a reason that function has to return unique_ptr
instead of unique_ptr? The conversion to ptr-to-base
could happen at the call site (where you always have an rvalue)
instead of on the return value.
Changing the return type to match the return value would avoid the
issue entirely though, as it would be valid with all C++11 compilers.
Re: [analyzer PATCH] Restore bootstrap with g++ 4.8.
On 14/06/24 11:37 +0100, Jonathan Wakely wrote:
On 14/06/24 11:26 +0100, Jonathan Wakely wrote:
On 14/06/24 10:36 +0100, Jonathan Wakely wrote:
On 07/06/24 19:40 +0100, Roger Sayle wrote:
This patch restores bootstrap when using g++ 4.8 as a host compiler.
Returning a std::unique_ptr requires a std::move on C++ compilers
(pre-C++17) that don't guarantee copy elision/return value optimization.
It doesn't though. The C++17 guaranteed copy elision rules are not
relevant here. This is about lookup for the constructor used in the
return statement, and whether that lookup considers the variable to be
an lvalue or an rvalue. C++11 already says this is valid:
i#include
std::unique_ptr f()
{
std::unique_ptr m;
return m;
}
See C++11 12.8 [class.copy] p31:
This elision of copy/move operations, called copy elision, is
permitted in the following circumstances (which may be combined to
eliminate multiple copies):
- in a return statement in a function with a class return type, when
the expression is the name of a non-volatile automatic object (other
than a function or catch-clause parameter) with the same cv-
unqualified type as the function return type, the copy/move
operation can be omitted by constructing the automatic object
directly into the function’s return value
and then p32:
When the criteria for elision of a copy operation are met or would
be met save for the fact that the source object is a function
parameter, and the object to be copied is designated by an lvalue,
overload resolution to select the constructor for the copy is first
performed as if the object were designated by an rvalue.
The constructor isn't required to be elided in C++11, but the compiler
is required to use a move constructor instead of a copy constructor,
if a move constructor is available. So you don't need to use std::move
on the return value.
And the code above compiles fine with gcc 4.8.5 on CentOS 7 (and even
with 4.7.1).
So the std::move calls you've added are redundant, and will cause
-Wredundant-move warnings.
What's the error you were seeing?
I can reproduce it:
/home/test/src/gcc/gcc/analyzer/constraint-manager.cc: In member function
‘std::unique_ptr ana::equiv_class::make_dump_widget(const
text_art::dump_widget_info&, unsigned int) const’:
/home/test/src/gcc/gcc/analyzer/constraint-manager.cc:1179:10: error: cannot bind
‘std::unique_ptr’ lvalue to
‘std::unique_ptr&&’
return ec_widget;
^
Odd ... I'm looking into it ...
Ah, the problem here is that the function's return type is
std::unique_ptr but the return value is
std::unique_ptr and that requires the converting
constructor, not the move constructor.
That *did* change after C++11, and isn't supported by G++ until 5.1
That changed with https://cplusplus.github.io/CWG/issues/1579.html
which is in C++14 and is a DR against C++11, but of course compilers
that implement the original C++11 rules don't support that DR.
Arguably, g++ should not give -Wredundant-move warnings here when
using the -std=c++11 dialect, because it's only redundant if the C++11
compiler implements that DR.
Is there a reason that function has to return unique_ptr
instead of unique_ptr? The conversion to ptr-to-base
could happen at the call site (where you always have an rvalue)
instead of on the return value.
Changing the return type to match the return value would avoid the
issue entirely though, as it would be valid with all C++11 compilers.
Re: [analyzer PATCH] Restore bootstrap with g++ 4.8.
On 14/06/24 11:26 +0100, Jonathan Wakely wrote:
On 14/06/24 10:36 +0100, Jonathan Wakely wrote:
On 07/06/24 19:40 +0100, Roger Sayle wrote:
This patch restores bootstrap when using g++ 4.8 as a host compiler.
Returning a std::unique_ptr requires a std::move on C++ compilers
(pre-C++17) that don't guarantee copy elision/return value optimization.
It doesn't though. The C++17 guaranteed copy elision rules are not
relevant here. This is about lookup for the constructor used in the
return statement, and whether that lookup considers the variable to be
an lvalue or an rvalue. C++11 already says this is valid:
i#include
std::unique_ptr f()
{
std::unique_ptr m;
return m;
}
See C++11 12.8 [class.copy] p31:
This elision of copy/move operations, called copy elision, is
permitted in the following circumstances (which may be combined to
eliminate multiple copies):
- in a return statement in a function with a class return type, when
the expression is the name of a non-volatile automatic object (other
than a function or catch-clause parameter) with the same cv-
unqualified type as the function return type, the copy/move
operation can be omitted by constructing the automatic object
directly into the function’s return value
and then p32:
When the criteria for elision of a copy operation are met or would
be met save for the fact that the source object is a function
parameter, and the object to be copied is designated by an lvalue,
overload resolution to select the constructor for the copy is first
performed as if the object were designated by an rvalue.
The constructor isn't required to be elided in C++11, but the compiler
is required to use a move constructor instead of a copy constructor,
if a move constructor is available. So you don't need to use std::move
on the return value.
And the code above compiles fine with gcc 4.8.5 on CentOS 7 (and even
with 4.7.1).
So the std::move calls you've added are redundant, and will cause
-Wredundant-move warnings.
What's the error you were seeing?
I can reproduce it:
/home/test/src/gcc/gcc/analyzer/constraint-manager.cc: In member function
‘std::unique_ptr ana::equiv_class::make_dump_widget(const
text_art::dump_widget_info&, unsigned int) const’:
/home/test/src/gcc/gcc/analyzer/constraint-manager.cc:1179:10: error: cannot bind
‘std::unique_ptr’ lvalue to
‘std::unique_ptr&&’
return ec_widget;
^
Odd ... I'm looking into it ...
Ah, the problem here is that the function's return type is
std::unique_ptr but the return value is
std::unique_ptr and that requires the converting
constructor, not the move constructor.
That *did* change after C++11, and isn't supported by G++ until 5.1
Is there a reason that function has to return unique_ptr
instead of unique_ptr? The conversion to ptr-to-base
could happen at the call site (where you always have an rvalue)
instead of on the return value.
Re: [analyzer PATCH] Restore bootstrap with g++ 4.8.
On 14/06/24 10:36 +0100, Jonathan Wakely wrote:
On 07/06/24 19:40 +0100, Roger Sayle wrote:
This patch restores bootstrap when using g++ 4.8 as a host compiler.
Returning a std::unique_ptr requires a std::move on C++ compilers
(pre-C++17) that don't guarantee copy elision/return value optimization.
It doesn't though. The C++17 guaranteed copy elision rules are not
relevant here. This is about lookup for the constructor used in the
return statement, and whether that lookup considers the variable to be
an lvalue or an rvalue. C++11 already says this is valid:
i#include
std::unique_ptr f()
{
std::unique_ptr m;
return m;
}
See C++11 12.8 [class.copy] p31:
This elision of copy/move operations, called copy elision, is
permitted in the following circumstances (which may be combined to
eliminate multiple copies):
- in a return statement in a function with a class return type, when
the expression is the name of a non-volatile automatic object (other
than a function or catch-clause parameter) with the same cv-
unqualified type as the function return type, the copy/move
operation can be omitted by constructing the automatic object
directly into the function’s return value
and then p32:
When the criteria for elision of a copy operation are met or would
be met save for the fact that the source object is a function
parameter, and the object to be copied is designated by an lvalue,
overload resolution to select the constructor for the copy is first
performed as if the object were designated by an rvalue.
The constructor isn't required to be elided in C++11, but the compiler
is required to use a move constructor instead of a copy constructor,
if a move constructor is available. So you don't need to use std::move
on the return value.
And the code above compiles fine with gcc 4.8.5 on CentOS 7 (and even
with 4.7.1).
So the std::move calls you've added are redundant, and will cause
-Wredundant-move warnings.
What's the error you were seeing?
I can reproduce it:
/home/test/src/gcc/gcc/analyzer/constraint-manager.cc: In member function
‘std::unique_ptr ana::equiv_class::make_dump_widget(const
text_art::dump_widget_info&, unsigned int) const’:
/home/test/src/gcc/gcc/analyzer/constraint-manager.cc:1179:10: error: cannot bind
‘std::unique_ptr’ lvalue to
‘std::unique_ptr&&’
return ec_widget;
^
Odd ... I'm looking into it ...
Re: [analyzer PATCH] Restore bootstrap with g++ 4.8.
On 07/06/24 19:40 +0100, Roger Sayle wrote:
This patch restores bootstrap when using g++ 4.8 as a host compiler.
Returning a std::unique_ptr requires a std::move on C++ compilers
(pre-C++17) that don't guarantee copy elision/return value optimization.
It doesn't though. The C++17 guaranteed copy elision rules are not
relevant here. This is about lookup for the constructor used in the
return statement, and whether that lookup considers the variable to be
an lvalue or an rvalue. C++11 already says this is valid:
i#include
std::unique_ptr f()
{
std::unique_ptr m;
return m;
}
See C++11 12.8 [class.copy] p31:
This elision of copy/move operations, called copy elision, is
permitted in the following circumstances (which may be combined to
eliminate multiple copies):
- in a return statement in a function with a class return type, when
the expression is the name of a non-volatile automatic object (other
than a function or catch-clause parameter) with the same cv-
unqualified type as the function return type, the copy/move
operation can be omitted by constructing the automatic object
directly into the function’s return value
and then p32:
When the criteria for elision of a copy operation are met or would
be met save for the fact that the source object is a function
parameter, and the object to be copied is designated by an lvalue,
overload resolution to select the constructor for the copy is first
performed as if the object were designated by an rvalue.
The constructor isn't required to be elided in C++11, but the compiler
is required to use a move constructor instead of a copy constructor,
if a move constructor is available. So you don't need to use std::move
on the return value.
And the code above compiles fine with gcc 4.8.5 on CentOS 7 (and even
with 4.7.1).
So the std::move calls you've added are redundant, and will cause
-Wredundant-move warnings.
What's the error you were seeing?
Bootstrapped on x86_64-pc-linux-gnu using both gcc 4.8.5 (system) and
gcc 10.2.1 (using "scl enable devetoolset-10") as host compilers.
Ok for mainline?
2024-06-07 Roger Sayle
gcc/analyzer/ChangeLog
* constraint-manager.cc (equiv_class::make_dump_widget): Use
std::move to return a std::unique_ptr.
(bounded_ranges_constraint::make_dump_widget): Likewise.
(constraint_manager::make_dump_widget): Likewise.
* program_state.cc (sm_state_map::make_dump_widget): Likewise.
(program_state::make_dump_widget): Likewise.
* region-model.cc (region_to_value_map::make_dump_widget): Likewise.
(region_model::make_dump_widget): Likewise.
* region.cc (region::make_dump_widget): Likewise.
* store.cc (binding_cluster::make_dump_widget): Likewise.
(store::make_dump_widget): Likewise.
* svalue.cc (svalue::make_dump_widget): Likewise.
Thanks in advance,
Roger
--
diff --git a/gcc/analyzer/constraint-manager.cc
b/gcc/analyzer/constraint-manager.cc
index 707385d..883f33b 100644
--- a/gcc/analyzer/constraint-manager.cc
+++ b/gcc/analyzer/constraint-manager.cc
@@ -1176,7 +1176,7 @@ equiv_class::make_dump_widget (const
text_art::dump_widget_info &dwi,
ec_widget->add_child (tree_widget::make (dwi, &pp));
}
- return ec_widget;
+ return std::move (ec_widget);
}
/* Generate a hash value for this equiv_class.
@@ -1500,7 +1500,7 @@ make_dump_widget (const text_art::dump_widget_info &dwi)
const
(tree_widget::from_fmt (dwi, nullptr,
"ec%i bounded ranges", m_ec_id.as_int ()));
m_ranges->add_to_dump_widget (*brc_widget.get (), dwi);
- return brc_widget;
+ return std::move (brc_widget);
}
bool
@@ -1853,7 +1853,7 @@ constraint_manager::make_dump_widget (const
text_art::dump_widget_info &dwi) con
if (cm_widget->get_num_children () == 0)
return nullptr;
- return cm_widget;
+ return std::move (cm_widget);
}
/* Attempt to add the constraint LHS OP RHS to this constraint_manager.
diff --git a/gcc/analyzer/program-state.cc b/gcc/analyzer/program-state.cc
index dc2d4bd..efaf569 100644
--- a/gcc/analyzer/program-state.cc
+++ b/gcc/analyzer/program-state.cc
@@ -382,7 +382,7 @@ sm_state_map::make_dump_widget (const
text_art::dump_widget_info &dwi,
state_widget->add_child (tree_widget::make (dwi, pp));
}
- return state_widget;
+ return std::move (state_widget);
}
/* Return true if no states have been set within this map
@@ -1247,7 +1247,7 @@ program_state::make_dump_widget (const
text_art::dump_widget_info &dwi) const
state_widget->add_child (smap->make_dump_widget (dwi, m_region_model));
}
- return state_widget;
+ return std::move (state_widget);
}
/* Update this program_state to reflect a top-level call to FUN.
diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
index d142d85..4fbc970 100644
--- a/gcc/analyzer/region-model.cc
+++ b/gcc/analyzer/region-model.cc
@@ -288,7 +288,7 @@ make_dump_widget (const text_art::dump_wi
Re: [analyzer PATCH] Restore bootstrap with g++ 4.8.
On Fri, 2024-06-07 at 19:40 +0100, Roger Sayle wrote: > > This patch restores bootstrap when using g++ 4.8 as a host compiler. > Returning a std::unique_ptr requires a std::move on C++ compilers > (pre-C++17) that don't guarantee copy elision/return value > optimization. > > Bootstrapped on x86_64-pc-linux-gnu using both gcc 4.8.5 (system) and > gcc 10.2.1 (using "scl enable devetoolset-10") as host compilers. > Ok for mainline? Yes, thanks. Sorry for the breakage. Dave > > > 2024-06-07 Roger Sayle > > gcc/analyzer/ChangeLog > * constraint-manager.cc (equiv_class::make_dump_widget): Use > std::move to return a std::unique_ptr. > (bounded_ranges_constraint::make_dump_widget): Likewise. > (constraint_manager::make_dump_widget): Likewise. > * program_state.cc (sm_state_map::make_dump_widget): > Likewise. > (program_state::make_dump_widget): Likewise. > * region-model.cc (region_to_value_map::make_dump_widget): > Likewise. > (region_model::make_dump_widget): Likewise. > * region.cc (region::make_dump_widget): Likewise. > * store.cc (binding_cluster::make_dump_widget): Likewise. > (store::make_dump_widget): Likewise. > * svalue.cc (svalue::make_dump_widget): Likewise. > > Thanks in advance, > Roger > -- >
[analyzer PATCH] Restore bootstrap with g++ 4.8.
This patch restores bootstrap when using g++ 4.8 as a host compiler. Returning a std::unique_ptr requires a std::move on C++ compilers (pre-C++17) that don't guarantee copy elision/return value optimization. Bootstrapped on x86_64-pc-linux-gnu using both gcc 4.8.5 (system) and gcc 10.2.1 (using "scl enable devetoolset-10") as host compilers. Ok for mainline? 2024-06-07 Roger Sayle gcc/analyzer/ChangeLog * constraint-manager.cc (equiv_class::make_dump_widget): Use std::move to return a std::unique_ptr. (bounded_ranges_constraint::make_dump_widget): Likewise. (constraint_manager::make_dump_widget): Likewise. * program_state.cc (sm_state_map::make_dump_widget): Likewise. (program_state::make_dump_widget): Likewise. * region-model.cc (region_to_value_map::make_dump_widget): Likewise. (region_model::make_dump_widget): Likewise. * region.cc (region::make_dump_widget): Likewise. * store.cc (binding_cluster::make_dump_widget): Likewise. (store::make_dump_widget): Likewise. * svalue.cc (svalue::make_dump_widget): Likewise. Thanks in advance, Roger -- diff --git a/gcc/analyzer/constraint-manager.cc b/gcc/analyzer/constraint-manager.cc index 707385d..883f33b 100644 --- a/gcc/analyzer/constraint-manager.cc +++ b/gcc/analyzer/constraint-manager.cc @@ -1176,7 +1176,7 @@ equiv_class::make_dump_widget (const text_art::dump_widget_info &dwi, ec_widget->add_child (tree_widget::make (dwi, &pp)); } - return ec_widget; + return std::move (ec_widget); } /* Generate a hash value for this equiv_class. @@ -1500,7 +1500,7 @@ make_dump_widget (const text_art::dump_widget_info &dwi) const (tree_widget::from_fmt (dwi, nullptr, "ec%i bounded ranges", m_ec_id.as_int ())); m_ranges->add_to_dump_widget (*brc_widget.get (), dwi); - return brc_widget; + return std::move (brc_widget); } bool @@ -1853,7 +1853,7 @@ constraint_manager::make_dump_widget (const text_art::dump_widget_info &dwi) con if (cm_widget->get_num_children () == 0) return nullptr; - return cm_widget; + return std::move (cm_widget); } /* Attempt to add the constraint LHS OP RHS to this constraint_manager. diff --git a/gcc/analyzer/program-state.cc b/gcc/analyzer/program-state.cc index dc2d4bd..efaf569 100644 --- a/gcc/analyzer/program-state.cc +++ b/gcc/analyzer/program-state.cc @@ -382,7 +382,7 @@ sm_state_map::make_dump_widget (const text_art::dump_widget_info &dwi, state_widget->add_child (tree_widget::make (dwi, pp)); } - return state_widget; + return std::move (state_widget); } /* Return true if no states have been set within this map @@ -1247,7 +1247,7 @@ program_state::make_dump_widget (const text_art::dump_widget_info &dwi) const state_widget->add_child (smap->make_dump_widget (dwi, m_region_model)); } - return state_widget; + return std::move (state_widget); } /* Update this program_state to reflect a top-level call to FUN. diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc index d142d85..4fbc970 100644 --- a/gcc/analyzer/region-model.cc +++ b/gcc/analyzer/region-model.cc @@ -288,7 +288,7 @@ make_dump_widget (const text_art::dump_widget_info &dwi) const sval->dump_to_pp (pp, true); w->add_child (text_art::tree_widget::make (dwi, pp)); } - return w; + return std::move (w); } /* Attempt to merge THIS with OTHER, writing the result @@ -556,7 +556,7 @@ region_model::make_dump_widget (const text_art::dump_widget_info &dwi) const m_mgr->get_store_manager ())); model_widget->add_child (m_constraints->make_dump_widget (dwi)); model_widget->add_child (m_dynamic_extents.make_dump_widget (dwi)); - return model_widget; + return std::move (model_widget); } /* Assert that this object is valid. */ diff --git a/gcc/analyzer/region.cc b/gcc/analyzer/region.cc index 71bae97..050feb6 100644 --- a/gcc/analyzer/region.cc +++ b/gcc/analyzer/region.cc @@ -1119,7 +1119,7 @@ region::make_dump_widget (const text_art::dump_widget_info &dwi, if (m_parent) w->add_child (m_parent->make_dump_widget (dwi, "parent")); - return w; + return std::move (w); } void diff --git a/gcc/analyzer/store.cc b/gcc/analyzer/store.cc index d14cfa3..b20bc29 100644 --- a/gcc/analyzer/store.cc +++ b/gcc/analyzer/store.cc @@ -1489,7 +1489,7 @@ binding_cluster::make_dump_widget (const text_art::dump_widget_info &dwi, m_map.add_to_tree_widget (*cluster_widget, dwi); - return cluster_widget; + return std::move (cluster_widget); } } @@ -2766,7 +2766,7 @@ store::make_dump_widget (const text_art::dump_widget_info &dwi, store_widget->add_child (std::move (parent_reg_widget)); } - return store_widget; + return std::move (store_widget); } /* Get any svalue bound to REG, or NULL. */ diff --git a/gcc/analyzer/svalue.cc b/gcc/analyzer/svalue.cc i
Re: [PATCH] Restore bootstrap on x86_64-pc-linux-gnu
On Tue, Feb 22, 2022 at 2:40 PM Roger Sayle wrote: > > > > This patch resolves the bootstrap failure on x86_64-pc-linux-gnu. > > Is this sufficiently "obvious" in stage4, or should I wait for the bootstrap > > and regression testing to complete? Please just bootstrap the compiler. > > > 2022-02-22 Roger Sayle > > > > gcc/ChangeLog > > * config/i386/i386-expand.cc (ix86_expand_cmpxchg_loop): Restore > > bootstrap. OK. Thanks, Uros. > > > > Cheers, > > Roger > > -- > > >
[PATCH] Restore bootstrap on x86_64-pc-linux-gnu
This patch resolves the bootstrap failure on x86_64-pc-linux-gnu.
Is this sufficiently "obvious" in stage4, or should I wait for the bootstrap
and regression testing to complete?
2022-02-22 Roger Sayle
gcc/ChangeLog
* config/i386/i386-expand.cc (ix86_expand_cmpxchg_loop): Restore
bootstrap.
Cheers,
Roger
--
diff --git a/gcc/config/i386/i386-expand.cc b/gcc/config/i386/i386-expand.cc
index 7f7055b..faa0191 100644
--- a/gcc/config/i386/i386-expand.cc
+++ b/gcc/config/i386/i386-expand.cc
@@ -23287,11 +23287,11 @@ void ix86_expand_cmpxchg_loop (rtx *ptarget_bool, rtx
target_val,
switch (mode)
{
-case TImode:
+case E_TImode:
gendw = gen_atomic_compare_and_swapti_doubleword;
hmode = DImode;
break;
-case DImode:
+case E_DImode:
if (doubleword)
{
gendw = gen_atomic_compare_and_swapdi_doubleword;
@@ -23300,12 +23300,15 @@ void ix86_expand_cmpxchg_loop (rtx *ptarget_bool, rtx
target_val,
else
gen = gen_atomic_compare_and_swapdi_1;
break;
-case SImode:
- gen = gen_atomic_compare_and_swapsi_1; break;
-case HImode:
- gen = gen_atomic_compare_and_swaphi_1; break;
-case QImode:
- gen = gen_atomic_compare_and_swapqi_1; break;
+case E_SImode:
+ gen = gen_atomic_compare_and_swapsi_1;
+ break;
+case E_HImode:
+ gen = gen_atomic_compare_and_swaphi_1;
+ break;
+case E_QImode:
+ gen = gen_atomic_compare_and_swapqi_1;
+ break;
default:
gcc_unreachable ();
}
[PATCH] Restore bootstrap
Committed as obvious. 2016-09-23 Richard Biener * hooks.h (hook_uint_uintp_false): Declare. Index: gcc/hooks.h === --- gcc/hooks.h (revision 240386) +++ gcc/hooks.h (working copy) @@ -76,6 +76,7 @@ extern void hook_void_tree (tree); extern void hook_void_tree_treeptr (tree, tree *); extern void hook_void_int_int (int, int); extern void hook_void_gcc_optionsp (struct gcc_options *); +extern bool hook_uint_uintp_false (unsigned int, unsigned int *); extern int hook_int_uint_mode_1 (unsigned int, machine_mode); extern int hook_int_const_tree_0 (const_tree);
Re: [PATCH]: Restore bootstrap with gcc < 4.3
On Mon, Jun 13, 2016 at 11:23 AM, Uros Bizjak wrote:
> Hello!
>
> The new test finalization self tests fail wigh gcc < 4.3 due to the
> way need_finalization_p is defined:
>
> template
> static inline bool
> need_finalization_p ()
> {
> #if GCC_VERSION >= 4003
> return !__has_trivial_destructor (T);
> #else
> return true;
> #endif
> }
>
> It is obvious that checking for
>
>ASSERT_FALSE (need_finalization_p ());
>
> will always fail. Checking need_finalization_p is meaningless with gcc < 4.3.
>
> 2016-06-13 Uros Bizjak
>
> * ggc-tests.c (test_finalization): Only test need_finalization_p
> for GCC_VERSION >= 4003.
>
> Bootstrapped on x86_64-linux-gnu, CentOS 5.11.
>
> OK for mainline?
Ok.
Richard.
> Uros.
>
> diff --git a/gcc/ggc-tests.c b/gcc/ggc-tests.c
> index 48eac03..7f97231 100644
> --- a/gcc/ggc-tests.c
> +++ b/gcc/ggc-tests.c
> @@ -190,8 +190,10 @@ int test_struct_with_dtor::dtor_call_count;
> static void
> test_finalization ()
> {
> +#if GCC_VERSION >= 4003
>ASSERT_FALSE (need_finalization_p ());
>ASSERT_TRUE (need_finalization_p ());
> +#endif
>
>/* Create some garbage. */
>const int count = 10;
[PATCH]: Restore bootstrap with gcc < 4.3
Hello!
The new test finalization self tests fail wigh gcc < 4.3 due to the
way need_finalization_p is defined:
template
static inline bool
need_finalization_p ()
{
#if GCC_VERSION >= 4003
return !__has_trivial_destructor (T);
#else
return true;
#endif
}
It is obvious that checking for
ASSERT_FALSE (need_finalization_p ());
will always fail. Checking need_finalization_p is meaningless with gcc < 4.3.
2016-06-13 Uros Bizjak
* ggc-tests.c (test_finalization): Only test need_finalization_p
for GCC_VERSION >= 4003.
Bootstrapped on x86_64-linux-gnu, CentOS 5.11.
OK for mainline?
Uros.
diff --git a/gcc/ggc-tests.c b/gcc/ggc-tests.c
index 48eac03..7f97231 100644
--- a/gcc/ggc-tests.c
+++ b/gcc/ggc-tests.c
@@ -190,8 +190,10 @@ int test_struct_with_dtor::dtor_call_count;
static void
test_finalization ()
{
+#if GCC_VERSION >= 4003
ASSERT_FALSE (need_finalization_p ());
ASSERT_TRUE (need_finalization_p ());
+#endif
/* Create some garbage. */
const int count = 10;
Re: [patch] Restore bootstrap on powerpc*-apple-darwin*
>> 2014-11-24 Rohit >> >> PR bootstrap/63703 >> * config/rs6000/darwin.h (REGISTER_NAMES): Update based on 32 newly >> added GCC hard register numbers for SPE high registers. >> > > IMO, it's obvious, and as you say, doesn't touch any other target. After further confirmations that it restores full bootstrap on powerpc-apple-darwin9, I’ve committed (r218058). I’ll backport to the 4.9 branch shortly. FX
Re: [patch] Restore bootstrap on powerpc*-apple-darwin*
On 24 Nov 2014, at 17:02, FX wrote: > Bootstrap is currently broken on ppc-darwin due to PR63703 > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703). > This is also broken on 4.9, and actually made it into the 4.9.2 release. > > This patch fixes it, restores bootstrap (well, it gets cc1 to build, at > least… I don’t have a ppc to test the full bootstrap), obviously doesn’t > affect other targets. > OK to commit to trunk and 4.9? > > FX > > > > 2014-11-24 Rohit > > PR bootstrap/63703 > * config/rs6000/darwin.h (REGISTER_NAMES): Update based on 32 newly > added GCC hard register numbers for SPE high registers. > > > IMO, it's obvious, and as you say, doesn't touch any other target. Iain
[patch] Restore bootstrap on powerpc*-apple-darwin*
Bootstrap is currently broken on ppc-darwin due to PR63703 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703). This is also broken on 4.9, and actually made it into the 4.9.2 release. This patch fixes it, restores bootstrap (well, it gets cc1 to build, at least… I don’t have a ppc to test the full bootstrap), obviously doesn’t affect other targets. OK to commit to trunk and 4.9? FX 2014-11-24 Rohit PR bootstrap/63703 * config/rs6000/darwin.h (REGISTER_NAMES): Update based on 32 newly added GCC hard register numbers for SPE high registers. ppc.diff Description: Binary data
[PATCH] Restore bootstrap (PR61757)
The following patch partially reverts r212352 to restore bootstrap
on i585-linux (where I reproduced and verified the fix). It makes
phicprop honor that loop-depth condition again which doing not
seems to cause a latent bug to pop up which miscompiles the stage2
compiler which in turn miscompiles stage3 genmodes.
I don't have time to track down the failure thus the revert below.
Also bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2014-07-10 Richard Biener
PR tree-optimization/61757
* tree-ssa-dom.c (loop_depth_of_name): Restore.
(propagate_rhs_into_lhs): Revert part of last change.
Index: gcc/tree-ssa-dom.c
===
--- gcc/tree-ssa-dom.c (revision 212352)
+++ gcc/tree-ssa-dom.c (working copy)
@@ -2639,6 +2639,33 @@ get_lhs_or_phi_result (gimple stmt)
gcc_unreachable ();
}
+/* Return the loop depth of the basic block of the defining statement of X.
+ This number should not be treated as absolutely correct because the loop
+ information may not be completely up-to-date when dom runs. However, it
+ will be relatively correct, and as more passes are taught to keep loop info
+ up to date, the result will become more and more accurate. */
+
+static int
+loop_depth_of_name (tree x)
+{
+ gimple defstmt;
+ basic_block defbb;
+
+ /* If it's not an SSA_NAME, we have no clue where the definition is. */
+ if (TREE_CODE (x) != SSA_NAME)
+return 0;
+
+ /* Otherwise return the loop depth of the defining statement's bb.
+ Note that there may not actually be a bb for this statement, if the
+ ssa_name is live on entry. */
+ defstmt = SSA_NAME_DEF_STMT (x);
+ defbb = gimple_bb (defstmt);
+ if (!defbb)
+return 0;
+
+ return bb_loop_depth (defbb);
+}
+
/* Propagate RHS into all uses of LHS (when possible).
RHS and LHS are derived from STMT, which is passed in solely so
@@ -2654,7 +2681,8 @@ static void
propagate_rhs_into_lhs (gimple stmt, tree lhs, tree rhs, bitmap
interesting_names)
{
/* First verify that propagation is valid. */
- if (may_propagate_copy (lhs, rhs))
+ if (may_propagate_copy (lhs, rhs)
+ && loop_depth_of_name (lhs) >= loop_depth_of_name (rhs))
{
use_operand_p use_p;
imm_use_iterator iter;
Re: [PATCH]: Restore bootstrap with --enable-build-with-cxx
On Wed, May 18, 2011 at 10:44 PM, Toon Moene wrote: > On 05/18/2011 10:31 PM, Richard Guenther wrote: > >> Not that I'm too excited to see GCC built with a C++ compiler (or even C++ >> features being used). > > Hmmm, you think using "false" as a value for a pointer-returning function is > just A-OK ? No, it isn't ;) Richard. > Duh, I'm glad I'm using Fortran, where the programmer isn't even supposed to > know what the value of .FALSE. is, because it is implementation dependent. > > -- > Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands > At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ > Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news >
Re: [PATCH]: Restore bootstrap with --enable-build-with-cxx
On 05/18/2011 10:31 PM, Richard Guenther wrote: Not that I'm too excited to see GCC built with a C++ compiler (or even C++ features being used). Hmmm, you think using "false" as a value for a pointer-returning function is just A-OK ? Duh, I'm glad I'm using Fortran, where the programmer isn't even supposed to know what the value of .FALSE. is, because it is implementation dependent. -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: [PATCH]: Restore bootstrap with --enable-build-with-cxx
On Wed, May 18, 2011 at 10:17 PM, Toon Moene wrote:
> On 05/18/2011 05:41 AM, Gabriel Dos Reis wrote:
>
>> On Tue, May 17, 2011 at 2:46 PM, Toon Moene wrote:
>
>>> On 05/17/2011 08:32 PM, Uros Bizjak wrote:
>>>
Tested on x86_64-pc-linux-gnu {, m32} with --enable-build-with-cxx.
Committed to mainline SVN as obvious.
>>>
>>> Does that mean that I can now remove the --disable-werror from my daily
>>> C++
>>> bootstrap run ?
>
> Well, that certainly worked, as exemplified by this:
>
> http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg01890.html
>
> At least that would enable my daily run (between 18:10 and 20:10 UTC) to
> catch -Werror mistakes ...
>
>>> It's great that some people understand the intricacies of the
>>> infight^H^H^H^H^H^H differences between the C and C++ type model.
>>>
>>> OK: 1/2 :-)
>>
>> I suspect this infight would vanish if we just switched, as we discussed
>> in the past.
>
> Perhaps it would just help if we implemented the next step of the plan
> (http://gcc.gnu.org/wiki/gcc-in-cxx):
>
> # "it would be a good thing to try forcing the C++ host compiler requirement
> for GCC 4.[7] with just building stage1 with C++ and stage2/3 with the
> stage1 C compiler. --disable-build-with-cxx would be a workaround for a
> missing C++ host compiler."
Or the other way around, build stage1 with the host C compiler, add
C++ to stage1-languages and build stage2/3 with the stageN C++ compiler.
That avoids the host C++ compiler requirement for now and excercises
the libstdc++ linking issues.
But yes, somebody has to go forward to implement either (or both) variants.
Not that I'm too excited to see GCC built with a C++ compiler (or even C++
features being used).
Richard.
Re: [PATCH]: Restore bootstrap with --enable-build-with-cxx
On 05/18/2011 05:41 AM, Gabriel Dos Reis wrote:
On Tue, May 17, 2011 at 2:46 PM, Toon Moene wrote:
On 05/17/2011 08:32 PM, Uros Bizjak wrote:
Tested on x86_64-pc-linux-gnu {, m32} with --enable-build-with-cxx.
Committed to mainline SVN as obvious.
Does that mean that I can now remove the --disable-werror from my daily C++
bootstrap run ?
Well, that certainly worked, as exemplified by this:
http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg01890.html
At least that would enable my daily run (between 18:10 and 20:10 UTC) to
catch -Werror mistakes ...
It's great that some people understand the intricacies of the
infight^H^H^H^H^H^H differences between the C and C++ type model.
OK: 1/2 :-)
I suspect this infight would vanish if we just switched, as we discussed
in the past.
Perhaps it would just help if we implemented the next step of the plan
(http://gcc.gnu.org/wiki/gcc-in-cxx):
# "it would be a good thing to try forcing the C++ host compiler
requirement for GCC 4.[7] with just building stage1 with C++ and
stage2/3 with the stage1 C compiler. --disable-build-with-cxx would be a
workaround for a missing C++ host compiler."
Of course, that still wouldn't make it possible to implement C++
solutions for C hacks because the "--disable-build-with-cxx" crowd would
cry "foul" over this ...
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: [PATCH]: Restore bootstrap with --enable-build-with-cxx
On Tue, May 17, 2011 at 2:46 PM, Toon Moene wrote:
> On 05/17/2011 08:32 PM, Uros Bizjak wrote:
>
>> Tested on x86_64-pc-linux-gnu {, m32} with --enable-build-with-cxx.
>> Committed to mainline SVN as obvious.
>
> Does that mean that I can now remove the --disable-werror from my daily C++
> bootstrap run ?
>
> It's great that some people understand the intricacies of the
> infight^H^H^H^H^H^H differences between the C and C++ type model.
>
> OK: 1/2 :-)
I suspect this infight would vanish if we just switched, as we discussed
in the past.
-- Gaby
Re: [PATCH]: Restore bootstrap with --enable-build-with-cxx
On 05/17/2011 08:32 PM, Uros Bizjak wrote:
Tested on x86_64-pc-linux-gnu {, m32} with --enable-build-with-cxx.
Committed to mainline SVN as obvious.
Does that mean that I can now remove the --disable-werror from my daily
C++ bootstrap run ?
It's great that some people understand the intricacies of the
infight^H^H^H^H^H^H differences between the C and C++ type model.
OK: 1/2 :-)
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
[PATCH]: Restore bootstrap with --enable-build-with-cxx
Hello!
2011-05-17 Uros Bizjak
* ipa-inline-analysis.c (inline_node_duplication_hook): Initialize
info->entry with 0
* tree-inline.c (maybe_inline_call_in_expr): Initialize
id.transform_lang_insert_block with NULL.
Tested on x86_64-pc-linux-gnu {, m32} with --enable-build-with-cxx.
Committed to mainline SVN as obvious.
Uros.
Index: ipa-inline-analysis.c
===
--- ipa-inline-analysis.c (revision 173832)
+++ ipa-inline-analysis.c (working copy)
@@ -702,7 +702,7 @@ inline_node_duplication_hook (struct cgr
bool inlined_to_p = false;
struct cgraph_edge *edge;
- info->entry = false;
+ info->entry = 0;
VEC_safe_grow_cleared (tree, heap, known_vals, count);
for (i = 0; i < count; i++)
{
Index: tree-inline.c
===
--- tree-inline.c (revision 173832)
+++ tree-inline.c (working copy)
@@ -5232,7 +5232,7 @@ maybe_inline_call_in_expr (tree exp)
id.transform_call_graph_edges = CB_CGE_DUPLICATE;
id.transform_new_cfg = false;
id.transform_return_to_modify = true;
- id.transform_lang_insert_block = false;
+ id.transform_lang_insert_block = NULL;
/* Make sure not to unshare trees behind the front-end's back
since front-end specific mechanisms may rely on sharing. */
