bootstrap/10053: weak declaration must precede definition errors on OSF 4.0d in libsupc++
>Number: 10053 >Category: bootstrap >Synopsis: weak declaration must precede definition errors on OSF 4.0d in >libsupc++ >Confidential: no >Severity: serious >Priority: medium >Responsible:unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Thu Mar 13 05:16:00 UTC 2003 >Closed-Date: >Last-Modified: >Originator: [EMAIL PROTECTED] >Release:3.4 20030312 >Organization: >Environment: alpha OSF 4.0d bootstraping using gcc 3.3 20021102 >Description: /scratch/gareth/cvsvers/gcc/gccbuild/gcc/xgcc -shared-libgcc -B/scratch/gareth/cvsvers/gcc/gccbuild/gcc/ -nostdinc++ -L/scratch/gareth/cvsvers/gcc/gccbuild/alphaev56-dec-osf4.0d/libstdc++-v3/src -L/scratch/gareth/cvsvers/gcc/gccbuild/alphaev56-dec-osf4.0d/libstdc++-v3/src/.libs -B/home/gareth/alphaev56-dec-osf4.0d/bin/ -B/home/gareth/alphaev56-dec-osf4.0d/lib/ -isystem /home/gareth/alphaev56-dec-osf4.0d/include -isystem /home/gareth/alphaev56-dec-osf4.0d/sys-include -I../../../../gcc/libstdc++-v3/../gcc -I../../../../gcc/libstdc++-v3/../include -I/scratch/gareth/cvsvers/gcc/gccbuild/alphaev56-dec-osf4.0d/libstdc++-v3/include/alphaev56-dec-osf4.0d -I/scratch/gareth/cvsvers/gcc/gccbuild/alphaev56-dec-osf4.0d/libstdc++-v3/include -I../../../../gcc/libstdc++-v3/libsupc++ -O2 -g -O2 -mieee -g -O2 -mieee -fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -Winline -fdiagnostics-show-location=once -c ../../../../gcc/libstdc++-v3/libsupc++/eh_aux_runtime.cc -DPIC -o eh_aux_runtime.o ../../../../gcc/libstdc++-v3/libsupc++/eh_aux_runtime.cc:42: error: weak declaration of `std::exception::exception(const std::exception&)' must precede definition ../../../../gcc/libstdc++-v3/libsupc++/eh_aux_runtime.cc:42: error: weak declaration of `std::bad_cast::bad_cast(const std::bad_cast&)' must precede definition ../../../../gcc/libstdc++-v3/libsupc++/eh_aux_runtime.cc:52: error: weak declaration of `std::bad_typeid::bad_typeid(const std::bad_typeid&)' must precede definition Occurs duing make bootstrap. gcc mainline did build on this platform 4 months ago (but I havent tried since then - havent had access) The word weak doesnt occur anywhere in the preprocessed file - leading me to believe this is a c++ issue with default copy constructor declaration on this platform. >How-To-Repeat: error found with ../gcc/configure --prefix=/home/gareth --enable-version-specific-runtime-libs --enable-shared --with-stabs make bootstrap &> build.out & >Fix: Wish I knew. >Release-Note: >Audit-Trail: >Unformatted: gnatsweb-attachment Content-Type: application/octet-stream; name="eh_aux_runtime.ii" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="eh_aux_runtime.ii" IyAxICIuLi8uLi8uLi8uLi9nY2MvbGlic3RkYysrLXYzL2xpYnN1cGMrKy9laF9hdXhfcnVudGlt ZS5jYyIKIyAxICI8YnVpbHQtaW4+IgojIDEgIjxjb21tYW5kIGxpbmU+IgojIDEgIi4uLy4uLy4u Ly4uL2djYy9saWJzdGRjKystdjMvbGlic3VwYysrL2VoX2F1eF9ydW50aW1lLmNjIgojIDMxICIu Li8uLi8uLi8uLi9nY2MvbGlic3RkYysrLXYzL2xpYnN1cGMrKy9laF9hdXhfcnVudGltZS5jYyIK IyAxICIuLi8uLi8uLi8uLi9nY2MvbGlic3RkYysrLXYzL2xpYnN1cGMrKy90eXBlaW5mbyIgMQoj IDM4ICIuLi8uLi8uLi8uLi9nY2MvbGlic3RkYysrLXYzL2xpYnN1cGMrKy90eXBlaW5mbyIKIyAx ICIuLi8uLi8uLi8uLi9nY2MvbGlic3RkYysrLXYzL2xpYnN1cGMrKy9leGNlcHRpb24iIDEKIyA0 MCAiLi4vLi4vLi4vLi4vZ2NjL2xpYnN0ZGMrKy12My9saWJzdXBjKysvZXhjZXB0aW9uIgpleHRl cm4gIkMrKyIgewoKbmFtZXNwYWNlIHN0ZAp7CiMgNTIgIi4uLy4uLy4uLy4uL2djYy9saWJzdGRj KystdjMvbGlic3VwYysrL2V4Y2VwdGlvbiIKICBjbGFzcyBleGNlcHRpb24KICB7CiAgcHVibGlj OgogICAgZXhjZXB0aW9uKCkgdGhyb3coKSB7IH0KICAgIHZpcnR1YWwgfmV4Y2VwdGlvbigpIHRo cm93KCk7CgoKICAgIHZpcnR1YWwgY29uc3QgY2hhciogd2hhdCgpIGNvbnN0IHRocm93KCk7CiAg fTsKCgoKICBjbGFzcyBiYWRfZXhjZXB0aW9uIDogcHVibGljIGV4Y2VwdGlvbgogIHsKICBwdWJs aWM6CiAgICBiYWRfZXhjZXB0aW9uKCkgdGhyb3coKSB7IH0KCgogICAgdmlydHVhbCB+YmFkX2V4 Y2VwdGlvbigpIHRocm93KCk7CiAgfTsKCgogIHR5cGVkZWYgdm9pZCAoKnRlcm1pbmF0ZV9oYW5k bGVyKSAoKTsKCiAgdHlwZWRlZiB2b2lkICgqdW5leHBlY3RlZF9oYW5kbGVyKSAoKTsKCgogIHRl cm1pbmF0ZV9oYW5kbGVyIHNldF90ZXJtaW5hdGUodGVybWluYXRlX2hhbmRsZXIpIHRocm93KCk7 CgoKICB2b2lkIHRlcm1pbmF0ZSgpIF9fYXR0cmlidXRlX18gKChfX25vcmV0dXJuX18pKTsKCgog IHVuZXhwZWN0ZWRfaGFuZGxlciBzZXRfdW5leHBlY3RlZCh1bmV4cGVjdGVkX2hhbmRsZXIpIHRo cm93KCk7CgoKICB2b2lkIHVuZXhwZWN0ZWQoKSBfX2F0dHJpYnV0ZV9fICgoX19ub3JldHVybl9f KSk7CiMgMTAwICIuLi8uLi8uLi8uLi9nY2MvbGlic3RkYysrLXYzL2xpYnN1cGMrKy9leGNlcHRp b24iCiAgYm9vbCB1bmNhdWdodF9leGNlcHRpb24oKSB0aHJvdygpOwp9CgpuYW1lc3BhY2UgX19n bnVfY3h4CnsKIyAxMTUgIi4uLy4uLy4uLy4uL2djYy9saWJzdGRjKystdjMvbGlic3VwYysrL2V4 Y2VwdGlvbiIKICB2b2lkIF9fdmVyYm9zZV90ZXJtaW5hdGVfaGFuZGxlciAoKTsKfQoKfQojIDM5 ICIuLi8uLi8uLi8uLi9nY2MvbGlic3RkYysrLXYzL2xpYnN1cGMrKy90eXBlaW5mbyIgMgoKZXh0 ZXJuICJDKysiIHsKCm5hbWVzcGFjZSBfX2N4eGFiaXYxCnsKICBjbGFzcyBfX2NsYXNzX3R5cGVf aW5mbzsKfQojIDU1ICIuLi8uLi8uLi8uLi9nY2MvbGlic3RkYysrLXYzL2xpYnN1cGMrKy90eXBl aW5mbyIKbmFtZXNwYWNlIHN0ZAp7CgoKCgoKCiAgY2xhc3MgdHlwZV9pbmZvCiAgewogIHB1Ymxp YzoKCgoKCiAgICB2aXJ0dWFsIH50eXBlX2luZm8oKTsKCi
[Bug c++/58119] New: Invalid ambiguous default type conversion with only a single invalid conversion listed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58119
Bug ID: 58119
Summary: Invalid ambiguous default type conversion with only a
single invalid conversion listed.
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tilps at hotmail dot com
'Minimal' test case:
template
class Silly {
public:
Silly(type *value) {
data_ = value;
}
operator type*() const {
return data_;
}
template
operator Silly() const {
return Silly(data_);
}
private:
type *data_;
};
int main() {
Silly a(nullptr);
delete a;
}
Fails giving:
test.cc:20:10: error: ambiguous default type conversion from 'Silly'
delete a;
^
test.cc:20:10: error: candidate conversions include 'template
Silly::operator Silly() const [with other = other; type = int]'
test.cc:20:10: error: type 'class Silly' argument given to 'delete',
expected pointer
I believe that this code should be considered valid, the only valid type
conversion is via the operator type *() which then converts to void* for the
delete operator. I don't see any way that Silly could be considered
convertible, except via operator type *() - and as far as I was aware, only a
single implicit cast operator is allowed to be considered in a type conversion
chain.
Interestingly, the valid type conversion is not mentioned as a candidate, and
the candidate mentioned does not specify which template parameter type it would
use for the 'other' template parameter.
Ultimately this is a bit of a strange example - I was trying to resurrect some
legacy code with a particularly dumb (but heavily used) 'smart pointer' type.
But this code did work, at least as recently as 4.6 - and probably back before
3.2.
[Bug c++/98632] New: Warn about unspecified expression ordering for atomics with non-relaxed memory ordering.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98632 Bug ID: 98632 Summary: Warn about unspecified expression ordering for atomics with non-relaxed memory ordering. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tilps at hotmail dot com Target Milestone: --- C++ defines that execution ordering for expressions is largely unspecified. In cases where there are multiple atomic operations in an expression for which there is no standard required ordering, and if those atomic operations are marked with a non-relaxed memory ordering, it would be useful to have a warning. Since the compiler is technically free to reorder them in-spite of the memory ordering indicating that the user cares about the specific ordering. While it might be able to be argued that the warning should fire for any expression involving just a single atomic and some other expression component that would be unable to be reordered if the sub-expressions had been assigned to locals first, it seems that would be likely to have vastly more false positives than expressions that involve multiple atomic operations. So I would suggest only triggering for expressions involving multiple atomic operations.
[Bug c++/98632] Warn about unspecified expression ordering for atomics with non-relaxed memory ordering.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98632
--- Comment #2 from tilps at hotmail dot com ---
*rough sketch*
class TaskConsumer {
void run() {
if (taken_count_.load(std::memory_order_acquire) <
task_count_.load(std::memory_order_acquire)) {
taken_count_.fetch_add(1, std::memory_order_acq_rel);
// ... handle the new task...
}
}
void addTask() {
task_count_.fetch_add(1, std::memory_order_acq_rel);
}
void reset() {
task_count_.store(0, std::memory_order_release);
taken_count_.store(0, std::memory_order_release);
}
std::atomic task_count_;
std::atomic taken_count_;
};
The above is not a 'complete' code sample, just illustrative.
One thread is calling 'run' in a loop.
Other thread calls reset, then add task some number of times. Waits until it
knows the first thread has done all tasks (not covered in the code above, but
assume that it is thread-safe and establishes acquire/release ordering as
appropriate), then calls reset again and repeats the process.
In order for the 'if' statement to behave correctly taken count must be read
before task count. If task count is read first it can read the value in
task_count_ before reset, but the taken_count_ value after reset.
If an optimizer (not necessarily an existing gcc one) decides to reorder the if
statement because the standard says order is unspecified and it notices that
task_count_ is an earlier memory address to taken_count_ and presumes
reordering might give a small performance increase due to sequential memory
access and cpu prefetching assumptions... then the code breaks.
Thus I would like a warning pointing at that if statement with wording along
the lines of:
C++ standard does not guarantee ordering of evaluation in this expression, thus
the order of atomic operations with non-relaxed memory ordering in this
expression is unspecified. Extract them into separate expressions to guarantee
that the ordering is consistent with the memory ordering annotations.
