Re: c++/729: [parser]compiler does not recognize variable definition
Synopsis: [parser]compiler does not recognize variable definition State-Changed-From-To: suspended->closed State-Changed-By: gdr State-Changed-When: Sun Dec 29 13:14:02 2002 State-Changed-Why: Fixed in 3.4 by the new parser. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=729
[Bug c++/11582] Odd error message with dynamically sized template arg printing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11582 --- Comment #8 from Gabriel Dos Reis 2013-04-22 10:10:36 UTC --- (In reply to comment #7) > The '[(((sizetype)) + 1)]' is just awful. If we don't know the > actual type there, that is "int [size()]", then we should just print 'int []' > or 'int [size_t]' or something similar to denote a VLA. > > Surprisingly, Clang++ is even more confused: > > test.cc:6:3: error: no matching function for call to 'f' > f( buf ) ; > ^ > test.cc:2:28: note: candidate template ignored: could not match 'int' against > 'int' > template void f(int (&)[N]); >^ > test.cc:13:3: error: no matching function for call to 'f' > f( buf ) ; > ^ > test.cc:2:28: note: candidate template ignored: could not match 'int' against > 'int' > template void f(int (&)[N]); >^ Printing int[] or int[size_t] would be confusing too. Yes, Clang is not the gold standard.
[Bug c++/11582] Odd error message with dynamically sized template arg printing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11582
--- Comment #10 from Gabriel Dos Reis 2013-04-23
03:45:56 UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> > Printing int[] or int[size_t] would be confusing too.
>
> More confusing than int[(((sizetype)) + 1)] ?
>
> What about?
>
> t7881.cc: In function ‘void g()’:
> t7881.cc:6:10: error: no matching function for call to ‘f(int
> [{variable-length}])’
> t7881.cc:6:10: note: candidate is:
> t7881.cc:2:23: note: template void f(int (&)[N])
> t7881.cc:2:23: note: template argument deduction/substitution failed:
> t7881.cc:6:10: note: variable-sized array type is not a valid template
> argument
Remember that an "array type" as a function parameter is equivalent to a
pointer type.
[Bug c++/54401] New: Missing diagnostics about type-alias at class scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54401
Bug #: 54401
Summary: Missing diagnostics about type-alias at class scope
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
The following simple and innocuous (ill-formed)
programs leads g++ in C++11 mode to produce a
very misleading unhelpful diagnostic:
gauss[3:28]% cat b.C
template
struct X {
using type = T;
};
When compiled with g++ in C++11 mode, I get:
gauss[3:32]% ~/gnu/bin/g++ -std=c++11 b.C
b.C:3:10: error: expected nested-name-specifier before 'type'
using type = T;
^
b.C:3:10: error: using-declaration for non-member at class scope
b.C:3:15: error: expected ';' before '=' token
using type = T;
^
b.C:3:15: error: expected unqualified-id before '=' token
(you need monospace fonts to make sense of the carets in the diagnostics)
The real problem is that `T' is undeclared (presumably a template
type parameter.)
I would expect the compiler to accept the syntax as a valid
alias declaration, and complain later that `T' isn't in scope.
In short it should be semantics error, not a parse error.
[Bug c++/54401] Missing diagnostics about type-alias at class scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54401 Gabriel Dos Reis changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-29 Ever Confirmed|0 |1
[Bug c++/46983] Diagnostic about change in meaning of name in class misses some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46983 Gabriel Dos Reis changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.16 23:22:09 CC||gdr at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Gabriel Dos Reis 2010-12-16 23:22:09 UTC --- I agree that we should diagnose this case.
[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022 --- Comment #30 from Gabriel Dos Reis --- (In reply to Paolo Carlini from comment #27) > DR2058 is now WP, thus we are supposed to reassess this. Now, according to > the resolution, additional 'begin' and 'end' overloads shall *not* be added, > thus I understand that we are already fine, right? Indeed.
[Bug middle-end/57974] std::pow(std::complex(0),1) returns (-nan,-nan)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974 --- Comment #11 from Gabriel Dos Reis --- (In reply to Paolo Carlini from comment #10) > Gaby, do you have an opinion on this? Irrespective of the long double issue, > do you want me to re-enable (contra LWG 844) the pow(const complex<>&, int) > overload in C++11 mode? If you think so, I can do it. I think pow(const complex&,int) is lesser evil. So, yes, I will support re-enabling it. What would we run afoul, except the obvious standard letter? Would we be computing something wrong? -- Gaby
[Bug libstdc++/57997] Segmentation fault after returning valarray expression from an auto function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997 --- Comment #2 from Gabriel Dos Reis --- (In reply to Paolo Carlini from comment #1) > Gaby, can you help me with this? I think this is typical confusion about what valarray expressions are. f1() has some complicated return type that has essentially reference semantics (as permitted by the standard) and it returns a "morally" reference to the locally constructed temporary. The simplest fix is in the user code: do not assume valarray expressions in general have valarray types.
[Bug libstdc++/57997] Segmentation fault after returning valarray expression from an auto function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997 --- Comment #3 from Gabriel Dos Reis --- Also, there might be some interactions with move semantics; I don't know.
[Bug ada/58239] [4.9 regression] pretty-print.c:789: undefined reference to `operator delete(void*)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239
--- Comment #1 from Gabriel Dos Reis ---
Here is the definition of pretty_printer::~pretty_printer ()
at the location indicated:
pretty_printer::~pretty_printer ()
{
buffer->~output_buffer ();
XDELETE (buffer);
}
The macro XDELETE is defined in include/libiberty.h
as:
#define XDELETE(P) free ((void*) ℗)
So, I do not see use of any 'operator delete' from
that code.
Is someone trying to #define XDELETE to something else?
-- Gaby
[Bug ada/58239] [4.9 regression] pretty-print.c:789: undefined reference to `operator delete(void*)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239 --- Comment #2 from Gabriel Dos Reis --- OK, I see the emitted reference to 'operator delete', and I suspect I have an idea of why the compiler generated this reference even though it isn't used anywhere in the input source code. Why are we linking gnatlink with xgcc and not with xg++ -nostdc++?
[Bug ada/58239] [4.9 regression] pretty-print.c:789: undefined reference to `operator delete(void*)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239 --- Comment #5 from Gabriel Dos Reis --- (In reply to Andrew Pinski from comment #3) > (In reply to Gabriel Dos Reis from comment #2) > > OK, I see the emitted reference to 'operator delete', and I suspect I > > have an idea of why the compiler generated this reference even though > > it isn't used anywhere in the input source code. > > It is due to virtual deconstructors and in-charge vs out-of-charge > deconstructors happening. Indeed, that is what I figured after looking at the output of nm on pretty-printer.o. I should have caught that on my first reply.
[Bug ada/58239] [4.9 regression] pretty-print.c:789: undefined reference to `operator delete(void*)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239 --- Comment #6 from Gabriel Dos Reis --- (In reply to Eric Botcazou from comment #4) > > OK, I see the emitted reference to 'operator delete', and I suspect I > > have an idea of why the compiler generated this reference even though > > it isn't used anywhere in the input source code. > > > > Why are we linking gnatlink with xgcc and not with xg++ -nostdc++? > > Because we haven't had a real need up to now, IOW we always managed to > massage things so as to avoid the dependency. Maybe it's the end of the > road... Well, that was a latent bug in the existing code base. The Ada front-end (more specifically gnatmake, gnatlink and consorts) linked against "common" files from GCC source code, most of which are compiled or are C++ source files. It should have linked with xg++. I have a patch right out of the door while typing this message. I hope you get a chance to review and comment it. I only changed the parts that I empirically determined to be in trouble. I welcome your input as someone who has a broader view to see whether they are other executables that need to be linked with xg++. -- Gaby
[Bug ada/58239] [4.9 regression] pretty-print.c:789: undefined reference to `operator delete(void*)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239 --- Comment #7 from Gabriel Dos Reis --- (In reply to Eric Botcazou from comment #4) > > OK, I see the emitted reference to 'operator delete', and I suspect I > > have an idea of why the compiler generated this reference even though > > it isn't used anywhere in the input source code. > > > > Why are we linking gnatlink with xgcc and not with xg++ -nostdc++? > > Because we haven't had a real need up to now, IOW we always managed to > massage things so as to avoid the dependency. Maybe it's the end of the > road... One more thing: Ada was already using -static-libstdc++ to build those tools.
[Bug ada/58239] [4.9 regression] pretty-print.c:789: undefined reference to `operator delete(void*)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239
--- Comment #9 from Gabriel Dos Reis ---
(In reply to Iain Sandoe from comment #8)
> note that the patch at:
>
> http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01460.html
>
> is not quite enough to fix this on Darwin - since we use :
>
> %{static|static-libgcc|static-libstdc++:%:replace-outfile(-lstdc++
> libstdc++.a%s)}
>
> to implement -static-libstadc++.
>
> The relevant dir needs to be added as "-B" for this to work - unfortunately,
> I'm not able to look at this right now..
-static-libstdc++ was already being used before this patch. So, the "-B"
directories where already there.
[Bug ada/58239] [4.9 regression] pretty-print.c:789: undefined reference to `operator delete(void*)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239 --- Comment #12 from Gabriel Dos Reis --- (In reply to Iain Sandoe from comment #10) > also the gcc driver silently ignores -static-libstdc++. Isn't this the problem? > certainly, the -B options are passed when other gcc components are built (or > it would fail to bootstrap on Darwin). The Makefiles in gcc/ pass down those options in variables.
[Bug bootstrap/57900] /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57900 Gabriel Dos Reis changed: What|Removed |Added CC||gdr at gcc dot gnu.org --- Comment #4 from Gabriel Dos Reis --- (In reply to Jonathan Wakely from comment #3) > See the long thread starting at > http://gcc.gnu.org/ml/gcc/2013-07/msg00075.html > > If it's easy to solve I'm sure a patch would be welcomed :) In this specific case, the ease of developing a patch is to be dissociated from a willingness to accept that it is a problem.
[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880
Gabriel Dos Reis changed:
What|Removed |Added
CC||gdr at gcc dot gnu.org
--- Comment #13 from Gabriel Dos Reis 2011-11-02
12:22:26 UTC ---
(In reply to comment #2)
> Thus, to understand and clarify why this has not been noticed so far, you are
> on a target which doesn't support in the underlying C library these complex
> functions, right? Because normally (eg, on Linux) these days we just forward
> to
> __builtin_cacosh*, the code you are touching is just a "surrogate", a
> "fallback", which doesn't get right all the special cases, NaNs, infinity.
>
> Anyway, a similar tweak would touch also the C++11 version in std::
>
> Gaby, can you have a look to this, double check the patch? For your
> convenience
> the surrounding code is:
>
> template
> std::complex<_Tp>
> __complex_acosh(const std::complex<_Tp>& __z)
> {
> std::complex<_Tp> __t((__z.real() - __z.imag())
> * (__z.real() + __z.imag()) - _Tp(1.0),
> _Tp(2.0) * __z.real() * __z.imag());
> __t = std::sqrt(__t);
>
> return std::log(__t + __z);
> }
As I observed elsewhere, the test should be on the sign, no comparison
against 0.0, so that signed zero is handled correctly.
[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880 --- Comment #14 from Gabriel Dos Reis 2011-11-02 12:27:20 UTC --- (In reply to comment #9) > Created attachment 25654 [details] > BC2 Since we are talking about branch cut and prespectiving since zeros, I think we should avoid the the arithmetic z -/+ one, whee one is of a complex. Rather the computation should be be directly on the components. This is to prevent signed zeros to have their mutated.
[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880
--- Comment #17 from Gabriel Dos Reis 2011-11-02
12:48:23 UTC ---
(In reply to comment #16)
> Well, I guess this would be most of it:
>
> template
> std::complex<_Tp>
> __complex_acosh(const std::complex<_Tp>& __z)
> {
> return _Tp(2.0) * std::log(std::sqrt(_Tp(0.5) * (__z + _Tp(1.0)))
> + std::sqrt(_Tp(0.5) * (__z - _Tp(1.0;
> }
looks good -- hoping for log implementation to do the right thing.
[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880
--- Comment #18 from Gabriel Dos Reis 2011-11-02
12:48:47 UTC ---
(In reply to comment #16)
> Well, I guess this would be most of it:
>
> template
> std::complex<_Tp>
> __complex_acosh(const std::complex<_Tp>& __z)
> {
> return _Tp(2.0) * std::log(std::sqrt(_Tp(0.5) * (__z + _Tp(1.0)))
> + std::sqrt(_Tp(0.5) * (__z - _Tp(1.0;
> }
looks good -- hoping for log implementation to do the right thing.
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistent with gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200 Gabriel Dos Reis changed: What|Removed |Added CC||gdr at gcc dot gnu.org --- Comment #41 from Gabriel Dos Reis 2012-02-29 13:36:59 UTC --- (In reply to comment #40) > I haven't seen it mentioned in the discussion here, but in C++11, the > definition of is_modulo was clarified as: > > "True if the type is modulo. A type is modulo if, for any operation involving > +, -, or * on values of that type whose result would fall outside the range > [min(),max()], the value returned differs from the true value by an integer > multiple of max() - min() + 1." > > Do people have objections to switching numeric_limits::is_modulo to > false (setting it to true when -fwrapv is used can still be discussed > afterwards)? I agree with this. Thanks, Marc.
[Bug driver/52863] New: Enable -Wall by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52863 Bug #: 52863 Summary: Enable -Wall by default Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org title says all.
[Bug libstdc++/48101] New: obscure error message with std::set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48101
Summary: obscure error message with std::set
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
The error message displayed on the
following program is quite obscure
and has no apparent relation with
the actual error. Quite mystifying.
#include
int main() {
std::set s;
}
With my system compiler (GCC-4.5), I get:
In file included from
/usr/include/c++/4.5/x86_64-suse-linux/bits/c++allocator.h:34:0,
from /usr/include/c++/4.5/bits/allocator.h:48,
from /usr/include/c++/4.5/bits/stl_tree.h:63,
from /usr/include/c++/4.5/set:60,
from b.C:1:
/usr/include/c++/4.5/ext/new_allocator.h: In instantiation of
‘__gnu_cxx::new_allocator’:
/usr/include/c++/4.5/bits/allocator.h:87:5: instantiated from
‘std::allocator’
/usr/include/c++/4.5/bits/stl_set.h:90:61: instantiated from ‘std::set’
b.C:4:24: instantiated from here
/usr/include/c++/4.5/ext/new_allocator.h:79:7: error: ‘const _Tp*
__gnu_cxx::new_allocator<_Tp>::address(const _Tp&) const [with _Tp = const int,
const _Tp* = const int*, const _Tp& = const int&]’ cannot be overloaded
/usr/include/c++/4.5/ext/new_allocator.h:76:7: error: with ‘_Tp*
__gnu_cxx::new_allocator<_Tp>::address(_Tp&) const [with _Tp = const int, _Tp*
= const int*, _Tp& = const int&]’
Go and figure out what the actual error was (hint: use of 'const int')
when the compiler displays internals of libstdc++ with unoverloadable
address of operator (which the user never overloaded in the first place.)
-- Gaby
[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760
Gabriel Dos Reis changed:
What|Removed |Added
CC||gdr at gcc dot gnu.org
--- Comment #8 from Gabriel Dos Reis 2011-04-25
17:57:15 UTC ---
(In reply to comment #1)
> I don't think this is a library proper issue, how can it be? We have just:
>
> constexpr // In C++0x mode
> complex(float __r = 0.0f, float __i = 0.0f)
> : _M_value(__r + __i * 1.0fi) { }
I believe we need a compiler support to construct a complex
value from its independent components -- instead of the low-level
C-style assignments that we are currently forced to do (or use
multiplication.) I think that is the way to go.
-- Gaby
[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760
Gabriel Dos Reis changed:
What|Removed |Added
CC||jason at redhat dot com
--- Comment #10 from Gabriel Dos Reis 2011-04-25
21:38:59 UTC ---
(In reply to comment #9)
> I guess, in the 4.6.1 time frame we can only workaround the issue in C++03
> mode
> by doing the piecewise work in the body. I can maybe help for the compiler
> work
> too but I need more guidance: is there an agreement about the C1X inspired
> builtin suggested by Joseph? In case, can I have a more specific reference?
>
> I'm adding in CC Richi too, in case he has additional tips and/or hints about
> the builtin work..
I believe in 4.6.1 it should still be possible to have the initialization
from components. All we need is to be able to write
complex(float __r, float __i) : _M_value{__r,__i} { }
or
complex(float __r, float __i) : _M_value({__r, __i}) { }
the work that people are testing really isn't C++03, it is C++0x.
It is fine if the C people don't want it. But in C++0x, we already
have the syntax (so no parser surgery is needed). All that remains is
to have the C++ front-end elaborate that syntax into the proper
initialization (ideal outcome) or a sequence of assignment (less ideal.)
Note that we already have that syntax for iniialization of array members
and a _Complex is supposed to behave like a 2-element array...
It is good that Richi is in the CC (as a RM) but, I suspect Jason should
be too.
-- Gaby
[Bug libstdc++/48760] [4.6 / 4.7 Regression (?)] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760
--- Comment #14 from Gabriel Dos Reis 2011-04-26
14:12:35 UTC ---
(In reply to comment #12)
> (In reply to comment #9)
> > I guess, in the 4.6.1 time frame we can only workaround the issue in C++03
> > mode
> > by doing the piecewise work in the body. I can maybe help for the compiler
> > work
> > too but I need more guidance: is there an agreement about the C1X inspired
> > builtin suggested by Joseph? In case, can I have a more specific reference?
> >
> > I'm adding in CC Richi too, in case he has additional tips and/or hints
> > about
> > the builtin work..
>
> A __builtin_complex builtin should be almost trivial. It would be purely
> frontend sugar for frontends that lack a way to specify a complex value
> component-wise. The frontend would be resposible for lowering it to
> a COMPLEX_EXPR. I don't think the middle-end wants to deal with
> __builtin_complex as it already has a perfect matching tree code.
Agreed -- except since __builtin_complex is already a perfect match,
the front-end should just accept either
_M_value{r,i}
or
_M_value(r,i)
if it wanted to be C++03 compatible too. Either way, you say, there
is no need to involve the middle end.
>
> Now I understand C++0x might have a proper syntax already, so I'm not sure
> how it relates to this (C++) bug.
>
> What changed in 4.6 is that we put complex values in registers even at -O0.
that is fine (and appreciated!). It is unrelated to the bug though.
> You should be able to reproduce any issue in this bug in older releases
> with optimization turned on (given that the library implementation didn't
> change).
The bug is a source-level bug; the source code is written that way because
we don't have yet a good way to initialize at once GCC builtin COMPLEX_EXPR.
-- Gaby
[Bug libstdc++/48760] [4.6 Regression] std::complex constructor buggy in the face of NaN's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760 --- Comment #30 from Gabriel Dos Reis 2011-04-29 23:52:32 UTC --- (In reply to comment #29) > This is now fixed in 4_6-branch too in C++03 mode, not in C++0x mode, where we > would need list-initialization of __complex__. If people believe we can / > should do something else in the release branch, I'm all ears: if for example > people consider a better trade-off for the branch removing the constexpr from > the constructor in order to initialized in the body for C++0x mode too, I'm ok > with that. I'm of course biased here, but I value constexpr-ability over complex numbers with parts that are NaNs. *If* we cannot have list-initialization for _Complex, then I suggest we close this PR as WONTFIX.
[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022 Gabriel Dos Reis changed: What|Removed |Added CC||gdr at gcc dot gnu.org AssignedTo|paolo.carlini at oracle dot |unassigned at gcc dot |com |gnu.org --- Comment #5 from Gabriel Dos Reis 2011-05-17 15:04:48 UTC --- (In reply to comment #2) > To expand: *if* the '+' itself is allowed per the specs to return something != > std::valarray, and the specs only mandate std::begin and std::end overloads > taking std::valarray& and const std::valarray& I don't see where is the bug in > our implementation. Maybe a QoI issue? I'm not sure. Admittedly I haven't > followed the recent discussion about ranges in any detail, I may be missing > something. LWG failed to resist the longstanding temptation to turn valarray into yet another container. You can't turn it into an container and yet make is possible for implementations to EFFECTIVELY exploit the lack of aliasing guarantees. If looks like everytime I turn my back LWG jumps tto do something to valarray. Either we have a flood of begin/end functions decorated with __enable_if stuff or we make it a defect in LWG. Sigh.
[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022 --- Comment #7 from Gabriel Dos Reis 2011-05-17 15:14:04 UTC --- (In reply to comment #6) > Double Sigh! I was hoping very few overloads would be enough... If we are > really talking about many I would be in favor of raising the issue, indeed. The issue is even trickier than that: If you were allowed to write those functions, what would begin() and end() return? a pointer into a soon-to-be-destroyed valarray? I think this is a defect in the standard. I just sent an email. -- Gaby
[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022 --- Comment #13 from Gabriel Dos Reis 2011-05-17 16:24:57 UTC --- (In reply to comment #11) > All in all, now that I understand the issue with the temporary, this seems > really sort of a NAD, maybe the wording needs only clarifying that you don't > want to add std::begin and std::end overloads, no? yes, my recommendation (in the email I sent LWG reflector) was to remove the begin/end pairs -- at least for the version that takes a const valarray&.
[Bug libstdc++/49022] [C++0x] std::begin and std::end specialized for std::valarray with some operators are missing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022 --- Comment #12 from Gabriel Dos Reis 2011-05-17 16:23:37 UTC --- (In reply to comment #10) > For sure that works. > > Gaby, just to make sure we are on the same page: did you send a message to the > reflector about this issue already? Or do you want me (us) to do that? Shall > we > suspend this PR in the meanwhile? Yes, I did send an email to c++std-lib. Apparently, there is some kind of partial network outage at the TAMU CSE so there might be a delay. Yes, it makes sense to suspend this PR in the meantime.
[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022
--- Comment #24 from Gabriel Dos Reis 2011-06-14
13:54:13 UTC ---
(In reply to comment #18)
> It should be identical to
>
> auto&& range = v1 + v2;
> for (auto b = std::begin(range), e = std::end(range); b != e; ++b)
> { ... }
> (see 6.5.4 [stmt.ranged])
This will not work with expression template-based implementation
of valarray. The reason is that `range' may be a surrogate, and
you are likely to get rubbish addresses.
I urge people to drop range-based iteration on valarrays.
It wasn't something we were dieing for. It grew out of
someone's idea of "uniformity" that failed to appreciate
that a valarray is not your usual container.
- Gaby
[Bug libstdc++/49022] [C++0x][DR 2058] std::begin and std::end specialized for std::valarray with some operators are missing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022 --- Comment #25 from Gabriel Dos Reis 2011-06-14 14:01:30 UTC --- (In reply to comment #23) > Ok, now I see, it's the operator[] of _BinBase which returns by value, I > overlooked that. Yes, "val" in "valarray" stands for "value", e.g. a valarray is a fundamentally a value, from a conceptual point of view; not an object. Range-based "for" is fundamentally container-oriented in the sense that it assumes that the container is an *object* that resides in memory, and the iteration really visits each cell in that object. A valarray is a *value*, and each individual value in that array may be produced by any mean, e.g. surrogates.
[Bug libstdc++/48365] Non-constant references in std::valarray::operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48365 Gabriel Dos Reis changed: What|Removed |Added CC||gdr at gcc dot gnu.org --- Comment #5 from Gabriel Dos Reis 2011-06-14 14:17:54 UTC --- (In reply to comment #1) > Gaby, can you have a look to this issue? It seems to me that in general, given > the expression templates mechanism we have in place, something like > > k = k[0] * k,(1) > > where k is a valarray, cannot possibly work as intuitively expected, because > the multiplication is expanded "in place": operator= triggers the computation > of the new k[0] and then k[1] which definitely uses the new k[0], contrary to > intuition. Is this actually undefined behavior, like morally in > > operator*(const T& t, const valarray& v) > > t cannot be an element of v? Seems something falling under the special > features > of valarray wrt aliasing, but I don't see it mentioned anywhere in C++03. > > Interestingly, if I change (1) to > > k *= k[0] > > which should be in principle equivalent, the behavior is the same on GCC, > whereas another implementation of valarray agrees with GCC in this case. Yes, Paolo, you are right. Valarray computations assume absence of certain form of aliasing, and this appears to be one of them.
[Bug libstdc++/6257] C-library symbols enter global namespace
--- Comment #24 from gdr at integrable-solutions dot net 2006-04-30 23:05 --- Subject: Re: C-library symbols enter global namespace "marc dot glisse at normalesup dot org" <[EMAIL PROTECTED]> writes: | (In reply to comment #20) | > the | > very same source code would not be be portable across those targets. I don't | > think we would like that. Besides, more generally, I'm not at all sure that | > all the users would actually *like* the new behavior. | | I meant proposing it as a choice, with a flag like -fclean-global-namespace That is a non-starter. PR better suspended. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #31 from gdr at integrable-solutions dot net 2006-05-01 18:55 --- Subject: Re: hidden declarations klobber STL "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | Well, two comments: first, I cannot reproduce with current mainline. Second, | frankly, if the implication of the issue is that in the entire implementation | of we cannot use operator, only to allow the user to write | unrestricted operator, templates in the face of the ADL trickeries, then, well, | I don't think we are going to buy that. Before closing this I'm only curious to | know why mainline is fine, maybe, simply, ADL was too zelant here? Any language | lawyer kicking in? Why is operator, essential to libstdc++? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #32 from gdr at integrable-solutions dot net 2006-05-01 18:59 --- Subject: Re: hidden declarations klobber STL "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | --- Comment #14 from pcarlini at suse dot de 2006-04-20 09:37 --- | (In reply to comment #12) | > I don't think that the problem is in the STL. The STL can be as tricky as it | > wants, including use of operator,(). It should not be possible for the actual | > operator,()s I declared to hijack the STL the way that happened, because 1) my | > declarations were out of scope for the STL code and 2) their signatures did not | > match the STL call site. This suggests a compiler bug to me, not an STL | > mis-design. | | Actually, I'm not at all sure, given: 1- our vector<>::iterator not being a | built-in type; 2- ADL rules. 3- The nature of fill_n (templated on *both* _Size | and _OutputIterator). Again, I'm not a language lawyer, but I think that, | strictly speaking, the compiler may legally find and match your operator, Yes. | I can certainly patch fill_n to avoid the operator, no big deal, my question is | more general, whether, given our class-type vector<>::iterator, given the | "unrestrictedness" of many templates, given current ADL rules, | whether it makes sense for us to go that route trying piecewise to "improve" | now the library, in the current C++03 framework. I believe it makes sense to do so the extent we can -- we (e.g. *you*) did patch the library so that qualified call where OK, e.g. std::copy, where we did so only for implementation details. The use of operator, in this case is no different. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug libstdc++/26974] hidden declarations klobber STL
--- Comment #33 from gdr at integrable-solutions dot net 2006-05-01 19:02 --- Subject: Re: hidden declarations klobber STL "bangerth at dealii dot org" <[EMAIL PROTECTED]> writes: | I mean, it's a miracle your code actually does what you expect. :-)) -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
[Bug c++/27235] goto crossing P.O.D. initialization
--- Comment #12 from gdr at integrable-solutions dot net 2006-05-01 20:45 --- Subject: Re: goto crossing P.O.D. initialization "falk at debian dot org" <[EMAIL PROTECTED]> writes: | I think this is a valid request. While random language extensions aren't | useful, | compatibility with C99 is. Maybe somebody else can comment on this... You have to be more precise about what you mean by C99 compatibility. My take on this goto stuff, if it is not valid C++, it is valid C++. Period. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27235
[Bug c++/27235] goto crossing P.O.D. initialization
--- Comment #13 from gdr at integrable-solutions dot net 2006-05-01 20:47 --- Subject: Re: goto crossing P.O.D. initialization "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | PR 27252 (aka PR 9278) is another example where C and C++ diff and in fact was | just fixed for 4.2.0 for a bug report. These are just some examples of where C | and C++ differ. I fully agree. People have to be extra careful when they talk about compatibility with C99 where the C committee has carefully chosen to depart from C++. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27235
[Bug c++/27235] goto crossing P.O.D. initialization
--- Comment #14 from gdr at integrable-solutions dot net 2006-05-01 20:48 --- Subject: Re: goto crossing P.O.D. initialization "acahalan at gmail dot com" <[EMAIL PROTECTED]> writes: | I only ask that C compatibility be provided for code that would otherwise fail | to compile as C++. This makes code reuse much easier. Given prior existence in C++, I think logic would require that you ask gcc to be compatibile with g++. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27235
[Bug c++/27235] goto crossing P.O.D. initialization
--- Comment #16 from gdr at integrable-solutions dot net 2006-05-01 23:30 --- Subject: Re: goto crossing P.O.D. initialization "falk at debian dot org" <[EMAIL PROTECTED]> writes: | --- Comment #15 from falk at debian dot org 2006-05-01 20:55 --- | (In reply to comment #12) | > Subject: Re: goto crossing P.O.D. initialization | > | > "falk at debian dot org" <[EMAIL PROTECTED]> writes: | > | > | I think this is a valid request. While random language extensions aren't | > | useful, | > | compatibility with C99 is. Maybe somebody else can comment on this... | > | > You have to be more precise about what you mean by C99 compatibility. | | I have trouble seeing what might be unclear about this term. I suspect part of the problem is that everybody believes that his/her uses of the term are so clear that they he/she has trouble seeing anybody disagree with him/her. | I mean that code | that is valid C99 is accepted in C++ unless there is a good reason not to. And why not the other way around? I mean, codes that is valid C++ is accepted in C99 unless there is good reason not to. As far as I can see, that also is compatibility. | just like most of C89 is accepted in C++ unless there is a good reason not to. I suspect this is might be one the places things needs to be explained. If * only a subset of C89 is valid C++ and has same meaning as in C++, * C99 has carefully departed from both C89 and C++ why is it that "code that is valid C99 is accepted C++ unless there is a good reason not to"? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27235
[Bug libstdc++/27340] valarray uses __cos which may conflict with libm functions
--- Comment #7 from gdr at integrable-solutions dot net 2006-05-01 23:39 --- Subject: Re: valarray uses __cos which may conflict with libm functions "marc dot glisse at normalesup dot org" <[EMAIL PROTECTED]> writes: | (In reply to comment #4) | > Should all those private classes and functions be declared in some | > specific namespace std::glibcxx_private to have a single point of failure? | | Oups, I just noticed that was one of the roles of __gnu_cxx (although I don't | understand why this namespace is not a subnamespace of std:: as tr1 (or at | least contains a using namespace std;), Why shall it? Before people suggest more tricky playing with libstdc++ name spaces, I would recommand people understand that namespaces are not silver bullet against machivelic playing with names. | which would at the same time fix things | like getenv not being prefixed by std:: in ext/mt_allocator.h). That is a separate problem that does not require namespace nesting. Nesting namespaces does not come for free. You really need to understand its consequences (name lookp, overload resolution, etc.) before proposing it. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27340
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #57 from gdr at integrable-solutions dot net 2006-05-09 15:15 --- Subject: Re: __cplusplus defined to 1, should be 199711L "marc dot glisse at normalesup dot org" <[EMAIL PROTECTED]> writes: | (In reply to comment #30) | > Defines __cplusplus to 199711L and overrides it in c++config.h for solaris 8 | | Out of curiosity, why not deal with __cplusplus the same way as __STDC__ (0 for | standard headers and 1 elsewhere IIRC) instead, or even defining it to 1 | directly for this platform? If I include stdlib.h (not cstdlib), I won't | include c++config.h first, and it should cause trouble with this approach. other standard headers might directly or indrectly include , so any macro game should work properly. I see c++config.h as a "built-in" header that should be always there anyway we are processing a C++ program. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug c++/27560] template function not recognized when invoked with enum defined in function
--- Comment #3 from gdr at integrable-solutions dot net 2006-05-11 16:24
---
Subject: Re: New: template function not recognized when invoked with enum
defined in function
"ian at airs dot com" <[EMAIL PROTECTED]> writes:
| Compiling this file, with mainline, gcc 4.0, or 4.1
|
| template void f(t a) { }
| void g() { enum e { v }; f(v); }
|
| gives this error message:
|
| foo.cc: In function Âvoid g()Â:
| foo.cc:2: error: no matching function for call to Âf(g()::e)Â
|
| If the enum definition is moved out of the function, this works. With gcc
3.2,
| this works. I didn't try 3.4.
There is a core issue for this. We discussed it again at the last
meeting in Berlin. There are proposals to make it "just work", but
that is still in the open state.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27560
[Bug c++/27560] template function not recognized when invoked with enum defined in function
--- Comment #6 from gdr at integrable-solutions dot net 2006-05-11 16:47 --- Subject: Re: template function not recognized when invoked with enum defined in function "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | It was not hastly closed, the current standard says this is invalid. and the current standard is known to be defective in that aspect, which is why we had the core issue in the first place. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27560
[Bug c++/27560] template function not recognized when invoked with enum defined in function
--- Comment #9 from gdr at integrable-solutions dot net 2006-05-11 23:20 --- Subject: Re: template function not recognized when invoked with enum defined in function "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | (In reply to comment #7) | > This may be related to 20589, but I don't think it is the same issue. | It is the same issue because there is only one Defect report for the C++ | standard. They are not the same thing. However, somehow, both issues have been conglomerated in the same _topic_ -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27560
[Bug libstdc++/27579] no warning for the non-standard integral overloads of math functions
--- Comment #2 from gdr at integrable-solutions dot net 2006-05-12 21:47 --- Subject: Re: New: no warning for the non-standard integral overloads of math functions "marc dot glisse at normalesup dot org" <[EMAIL PROTECTED]> writes: | As a solution to "bug" 3181, integral overloads of many math functions (like | sqrt) were introduced. Would it be possible to add a warning when such | overloads are instantiated? I don't know how to do that with g++ (if it is not | possible, then it would be a nice feature to add). It would help people write | more portable code. this is a non-issue. PR should be closed. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27579
[Bug c++/25915] use ODR rules to make C++ objects not be TREE_PUBLIC
--- Comment #9 from gdr at integrable-solutions dot net 2006-06-21 19:43 --- Subject: Re: use ODR rules to make C++ objects not be TREE_PUBLIC "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Yes this is all undefined but I rather have it be diagnose than | having it be undefined behavior. interesting shift of perspective :-) -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25915
[Bug libstdc++/28080] header dependencies
--- Comment #8 from gdr at integrable-solutions dot net 2006-06-23 16:35 --- Subject: Re: header dependencies "chris at bubblescope dot net" <[EMAIL PROTECTED]> writes: | I did implement a version of this myself, basically by writing a | mapper around each container that did a few static_casts and mapped | the functions to a void* version of the container. However, having a | whole new bunch of inline functions causes problems for the | compiler, without providing (as far as I could measure) | significant reductions in the size of the executable. I'm not surprised. We should be very cautious about increasing abstraction penablty for the benefit of marginal reduction on header dependencies. Runtime performance of the library should not be under-emphasized. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28080
[Bug c/28152] Diagnostic about wrong use _Complex prints __complex__
--- Comment #3 from gdr at integrable-solutions dot net 2006-07-02 16:03 --- Subject: Re: Diagnostic about wrong use _Complex prints __complex__ "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Confirmed, we don't record in the preprocessor which keyword is | used, _Complex is treated the same as __complex__. Indeed. However, we can approximate a fix by testing whether we're compiling under C99, GNU99, or just C90, or C++. -- gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28152
[Bug c/28152] Diagnostic about wrong use _Complex prints __complex__
--- Comment #5 from gdr at integrable-solutions dot net 2006-07-02 16:37 --- Subject: Re: Diagnostic about wrong use _Complex prints __complex__ "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | (In reply to comment #3) | > Indeed. However, we can approximate a fix by testing whether we're | > compiling under C99, GNU99, or just C90, or C++. | | That would not work as _Complex is accepted in GNU90 more and with the C++ | front-end by default. Lookup the meaning of "approximation". -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28152
[Bug c++/28407] [4.2 regression] Issue with anonymous namespace
--- Comment #2 from gdr at integrable-solutions dot net 2006-07-17 16:51
---
Subject: Re: New: [4.2 regression] Issue with anonymous namespace
"jakub at redhat dot com" <[EMAIL PROTECTED]> writes:
| template
| const char *baz ()
| {
| return str;
| }
|
| namespace { char foo[] = "foo"; };
|
| const char *
| bar ()
| {
| return baz ();
| }
|
| used to compile before the "make anon-namespace non-public" changes and still
| compiles when the anon namespace is changed for a named namespace and using
| namespace below it.
This is a bug in the compiler. I have always warned people that the
unnamed namespace transformation to "static" should happen in the
*back-end*, not in the front-end using language rules, because the
language rules are slightly different in those cases. But, at the
time people said I was considering theoretical problems. The ability
to have the compiler do "would be nice" transformation should not take
over our ability for the compiler to have valid codes and generate
good executable.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28407
[Bug c++/28407] [4.2 regression] Issue with anonymous namespace
--- Comment #6 from gdr at integrable-solutions dot net 2006-07-17 20:19 --- Subject: Re: [4.2 regression] Issue with anonymous namespace "jason at redhat dot com" <[EMAIL PROTECTED]> writes: | --- Comment #3 from jason at redhat dot com 2006-07-17 19:53 --- | Subject: Re: [4.2 regression] Issue with anonymous namespace | | gdr at integrable-solutions dot net wrote: | > I have always warned people that the | > unnamed namespace transformation to "static" should happen in the | > *back-end*, not in the front-end using language rules, because the | > language rules are slightly different in those cases. | | I don't remember ever seeing you mention that before, but it does seem | like an interesting idea. Hi Jason, This transformation has been discussed several times. The last time I made again that statement was with respect to a PR whose number I can't remember right now. However, google gave a link to this http://gcc.gnu.org/ml/gcc/2004-01/msg02351.html http://gcc.gnu.org/ml/gcc/2004-01/msg02358.html the discussion is quite involved there, but I suspect it shows how difficult it is get the caution through. | Your comments in the PRs talk about not | changing the C++ linkage (which we obviously shouldn't), but not about | where to implement it. Basically what I'm saying is this: We should have two notions of linkage (1) one at the language level, as mandated by the language definition; (2) and one at the symbol level, that the middle-end, back-end and linker understand. Then we map the linkages in categrory (1) to those of category (2). So that would enable us to use "internal linkage" (or hidden visibilitty) at level (2) without affecting linkage at level 1. At the moment it looks like the tree reprsentation somehow conflates those two levels into a single one, leading to the current misbehaviour. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28407
[Bug libstdc++/7439] C99 compat: Can't use the name INFINITY in an enum.
--- Comment #8 from gdr at integrable-solutions dot net 2009-01-27 03:34 --- Subject: Re: C99 compat: Can't use the name INFINITY in an enum. On Mon, Jan 26, 2009 at 6:19 PM, bkoz at gcc dot gnu dot org > Thus, I am going to close this as WONTFIX. For C++0x, the case is INVALID, and > for open gcc branches the bug status is FIXED. > > Gaby, if I'm off on this please re-open. > > -benjamin I fully agree with your resolution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7439
[Bug c++/22238] [4.0/4.1 regression] '#'obj_type_ref' not supported by dump_expr
--- Comment #7 from gdr at integrable-solutions dot net 2005-11-16 19:05 --- Subject: Re: [4.0/4.1 regression] '#'obj_type_ref' not supported by dump_expr "mmitchel at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Gaby, please apply the simple OBJ_TYPE_REF patch so that we can remove the | regression markers from this PR. OK. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22238
[Bug c++/24657] [3.4/4.0/4.1 Regression] bizarre diagnostic when a member variable and a template parameter have the same name
--- Comment #7 from gdr at integrable-solutions dot net 2005-11-16 19:14 --- Subject: Re: [3.4/4.0/4.1 Regression] bizarre diagnostic on valid (?) constructor "bangerth at dealii dot org" <[EMAIL PROTECTED]> writes: | I'm pretty sure I've seen this somewhere before -- the question was indeed | which name should be looked up, the template name or the name of a member | variable. Indeed this is an issue. Discussion in on the -core reached the consensus that we could change the lookup rules for member templates so that template parameters for *member* templates would be searched, before members of the enclosing class. But I don't recall the issue has attained an advanced state yet. Note that in the older "issue", there actually are TWO separate issues. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24657
[Bug c++/24702] Koenig found functoid ref, but "cannot be used as a function"
--- Comment #3 from gdr at integrable-solutions dot net 2005-11-16 19:28 --- Subject: Re: Koenig found functoid ref, but "cannot be used as a function" "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Actually IIRC Koenig lookup only finds functions and not variables. That is incorrect. There is an active core language issue on "argument dependent name lookup specification." -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24702
[Bug libfortran/24902] COMPLEX_ASSIGN is wrong
--- Comment #2 from gdr at integrable-solutions dot net 2005-11-16 19:43 --- Subject: Re: New: COMPLEX_ASSIGN is wrong "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | The defintion of COMPLEX_ASSIGN is wrong, that is wrong according to Andrew. | This is in reference to PR 23497. In the reference to that thread, please do note that = yields an lvalue for built-in "="; in partiaular __imag__ z = r yields an lvalue. do whatever you want in the *middle end*, but be sure you don't transmute that basic semantics constraint. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24902
[Bug libfortran/24902] COMPLEX_ASSIGN is wrong
--- Comment #5 from gdr at integrable-solutions dot net 2005-11-16 20:24 --- Subject: Re: COMPLEX_ASSIGN is wrong "pinskia at physics dot uc dot edu" <[EMAIL PROTECTED]> writes: | Subject: Re: COMPLEX_ASSIGN is wrong | | > yields an lvalue. do whatever you want in the *middle end*, but be | > sure you don't transmute that basic semantics constraint. | | Gaby, it also prevents a huge amount of optimizations so what is | the difference from saying it is wrong? You're putting optimization before semantics; -that- is wrong. I'm not interested in the fastest program if it does not meet my needs. If __imag__ z yields a modifiable lvalue, then it follows, by ordinary language rules that it can be used on the left hand side of built-in "=". In C, the resulting expresion is an rvalue; in C++ it is an lvalue. No amount of bizarre extension should break those simple rules. | The issue comes down to what does | __imag__ a = b; really means. No, it comes down to what "__imag__ a" means. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24902
[Bug libfortran/24902] COMPLEX_ASSIGN is wrong
--- Comment #6 from gdr at integrable-solutions dot net 2005-11-16 20:27 --- Subject: Re: COMPLEX_ASSIGN is wrong "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | I should also note that: | http://gcc.gnu.org/onlinedocs/gcc/Complex.html#Complex | | recomends against using the extensions anyways. Exactly which sentence says so? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24902
[Bug middle-end/23497] [4.1 regression] Bogus 'is used uninitialized...' warning about std::complex
--- Comment #34 from gdr at integrable-solutions dot net 2005-11-16 20:29 --- Subject: Re: [4.1 regression] Bogus 'is used uninitialized...' warning about std::complex "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | I should also note that: | http://gcc.gnu.org/onlinedocs/gcc/Complex.html#Complex | recomends against using the extensions anyways. Exactly which sentence says that? It is an extension, useful to build libraries that cannot plug or wait to have C99 . You would have to explain with hard arguments why it should go. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
[Bug libfortran/24902] COMPLEX_ASSIGN is wrong
--- Comment #8 from gdr at integrable-solutions dot net 2005-11-16 20:39 --- Subject: Re: COMPLEX_ASSIGN is wrong "pinskia at physics dot uc dot edu" <[EMAIL PROTECTED]> writes: [...] | > Subject: Re: COMPLEX_ASSIGN is wrong | > | > "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | > | > | I should also note that: | > | http://gcc.gnu.org/onlinedocs/gcc/Complex.html#Complex | > | | > | recomends against using the extensions anyways. | > | > Exactly which sentence says so? | | "you should use the ISO C99 function" every time it mentions the | extenstions. (1) that is not the same as recommending against the extension; (2) how do you use ISO C99 functions to implement C99 , C++98 that interoperate with C99 _Complex and other libraries that predate C99 functions or on plateforms where C99 functions don't exist but the libraries need to be implemented anyway? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24902
[Bug libstdc++/24660] versioning weak symbols in libstdc++
--- Comment #9 from gdr at integrable-solutions dot net 2005-11-17 20:46 --- Subject: Re: versioning weak symbols in libstdc++ "jason at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | This code, like the testcase for c++/16021, works fine if the implementation | namespace is nested within std. I'm thinking of enforcing that | requirement in parse_using_directive; that would allow us to avoid | adding more special lookup rules. Do you see any problem with that | requirement? I'm for minimal invasion in the name lookup rules; so if that takes care of issues raised by Benjamin, I'm all for it. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660
[Bug c++/24928] static const objects should go to .rodata
--- Comment #3 from gdr at integrable-solutions dot net 2005-11-18 01:31 --- Subject: Re: New: Trivial static const objects should go to .rodata "msharov at hotmail dot com" <[EMAIL PROTECTED]> writes: | With the object being initialized at runtime as if it mattered. Because the | values of the member variables can not be changed after initialization, there | is no reason to do this at runtime. Because the constructor doesn't do | anything, this would not conflict with C++'s create-on-call mandate. Completely agreed. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24928
[Bug c++/24983] Needs a warning?
--- Comment #1 from gdr at integrable-solutions dot net 2005-11-22 02:46
---
Subject: Re: New: Needs a warning?
"igodard at pacbell dot net" <[EMAIL PROTECTED]> writes:
| struct foo { const void f(); };
| void foo::f(){}
|
| gets you:
|
| ~/ootbc/members/src$ g++ foo.cc -Wall
| foo.cc:2: error: prototype for `void foo::f()' does not match any in class
| `foo'
| foo.cc:1: error: candidate is: const void foo::f()
| foo.cc:2: error: `void foo::f()' and `const void foo::f()' cannot be
overloaded
Awful. Please assign it to me.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24983
[Bug c++/24983] Needs a warning?
--- Comment #4 from gdr at integrable-solutions dot net 2005-11-22 03:58 --- Subject: Re: Needs a warning? "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | earth:~>~/ia32_linux_gcc3_0/bin/gcc t.cc | t.cc:2: prototype for `void foo::f()' does not match any in class `foo' | t.cc:1: candidate is: const void foo::f() | earth:~>~/ia32_linux_gcc2_95//bin/gcc t.cc | t.cc:2: new declaration `void foo::f()' | t.cc:1: ambiguates old declaration `const void foo::f()' | | | I say that 3.0.x is the best if it is what we should say then we have a | regression. We should say: 'const void' is not a valid type and be done with it. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24983
[Bug c++/25006] failure "using" a name contained in a class
--- Comment #2 from gdr at integrable-solutions dot net 2005-11-23 19:36 --- Subject: Re: failure "using" a name contained in a class "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | ICC rejects it as invalid too: | t.cc(7): error: a class-qualified name is not allowed | using ::Foo::Bar::FooBar; // line 7 | | So does Comeau with the same error message. The construct is ill-formed -- sorry, someone needs to quote chapter and verse. I'll do that later if no one beats me at it. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25006
[Bug bootstrap/25009] Bootstrap: Failure to build doc/gcc.info
--- Comment #3 from gdr at integrable-solutions dot net 2005-11-24 03:38 --- Subject: Re: Bootstrap: Failure to build doc/gcc.info "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Actually this is invalid, you need to build with a clean object directory. That is bullshit. what about bubblestrap and the like? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25009
[Bug bootstrap/25009] Bootstrap: Failure to build doc/gcc.info
--- Comment #7 from gdr at integrable-solutions dot net 2005-11-24 09:01 --- Subject: Re: Bootstrap: Failure to build doc/gcc.info "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | (In reply to comment #4) | > still does not work with bubblestrap and friends | | After a clean build? YES. | See http://gcc.gnu.org/ml/gcc/2005-11/msg01173.html That does not solve the problem. I did not experience that before. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25009
[Bug bootstrap/25009] Bootstrap: Failure to build doc/gcc.info
--- Comment #8 from gdr at integrable-solutions dot net 2005-11-24 09:03 --- Subject: Re: Bootstrap: Failure to build doc/gcc.info "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | (In reply to comment #3) | > Subject: Re: Bootstrap: Failure to build doc/gcc.info | > "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | > | Actually this is invalid, you need to build with a clean object directory. | > That is bullshit. what about bubblestrap and the like? | | well are you bubblestrapping in the gcc directory of the objdir or the toplevel | directory, if the latter, maybe just maybe this is a bug. the gcc directory of the builddir. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25009
[Bug c++/25137] Warning "missing braces around initializer" causing problems with tr1::array
--- Comment #3 from gdr at integrable-solutions dot net 2005-11-28 16:15 --- Subject: Re: Warning "missing braces around initializer" causing problems with tr1::array "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | I don't see why the warning is not useful at all, in fact I rather | have the C++ standard fix their wording of TR1's array. it is not the C++ standard; but definitely a bug in the specification. he problem shoul dbe reported there. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137
[Bug c++/25137] Warning "missing braces around initializer" causing problems with tr1::array
--- Comment #4 from gdr at integrable-solutions dot net 2005-11-28 16:18
---
Subject: Re: New: Warning "missing braces around initializer" causing
problems with tr1::array
"chris at bubblescope dot net" <[EMAIL PROTECTED]> writes:
| The following code:
|
| struct S
| { int x[3]; };
|
| void f()
| { S s = {1,2,3};}
|
| With -Wmissing-braces (which is implied by -Wall, among others) gives:
|
| warning: missing braces around initializer for 'int [3]'
|
| In the specific case where a struct contains only a single array, adding the
| extra braces doesn't really seem that useful.
|
| The reason it would be nice to fix this that in the definition of tr1::array
in
| the TR1 specification (page 88, 6.2.2) says
|
| 2.An array is an aggregate ([dcl.init.aggr]) that can be initialized with the
| syntax
| array a = { initializer-list };
I believe there is a slight confusion between a "C-array" and a TR1
class-type called "array". You have found a bug in the TR1; would you
mind making a report?
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137
[Bug c++/25137] Warning "missing braces around initializer" causing problems with tr1::array
--- Comment #7 from gdr at integrable-solutions dot net 2005-11-28 18:46
---
Subject: Re: Warning "missing braces around initializer" causing problems with
tr1::array
"chris at bubblescope dot net" <[EMAIL PROTECTED]> writes:
| Actually, is a report really approriate? Writing array = {1,2,3} is
| perfectly valid C++, just warned about with -Wmissing-braces
You're absolutely right! I forgot 8.5.1/11!
Can't we have simple, general rules, without list of special cases? :-(
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137
[Bug c++/25156] [3.4/4.0/4.1 Regression] wrong error message (int instead of bool)
--- Comment #3 from gdr at integrable-solutions dot net 2005-11-29 17:48 --- Subject: Re: [3.4/4.0/4.1 Regression] wrong error message (int instead of bool) "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Hmm, it is looking at the wrong type, it is looking at the RESULT_DECL's type | instead of the FUNCTION_TYPE's type which has the correct type, I might fix | this later tonight. That is a combination of two things: (1) vestige of the old infamous named-returned value extension logic; (2) the default widening-strategy used in the compiler. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25156
[Bug c++/25156] [3.4/4.0/4.1 Regression] wrong error message (int instead of bool)
--- Comment #4 from gdr at integrable-solutions dot net 2005-11-29 18:02 --- Subject: Re: [3.4/4.0/4.1 Regression] wrong error message (int instead of bool) "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Hmm, it is looking at the wrong type, it is looking at the RESULT_DECL's type | instead of the FUNCTION_TYPE's type which has the correct type, I might fix | this later tonight. Try this *** ChangeLog (revision 107674) --- ChangeLog (local) *** *** 1,3 --- 1,10 + 2005-11-29 Gabriel Dos Reis <[EMAIL PROTECTED]> + + PR c++/25156 + * typeck.c (check_return_expr): Get the return-type from the + function declaration, now that the named-return value extension is + no longer existent. + 2005-11-30 Ben Elliston <[EMAIL PROTECTED]> * typeck.c (build_x_unary_op): Correct spelling in error message. *** typeck.c(revision 107674) --- typeck.c(local) *** check_return_expr (tree retval, bool *no *** 6257,6270 return retval; } ! /* When no explicit return-value is given in a function with a named ! return value, the named return value is used. */ ! result = DECL_RESULT (current_function_decl); ! valtype = TREE_TYPE (result); gcc_assert (valtype != NULL_TREE); fn_returns_value_p = !VOID_TYPE_P (valtype); - if (!retval && DECL_NAME (result) && fn_returns_value_p) - retval = result; /* Check for a return statement with no return value in a function that's supposed to return a value. */ --- 6257,6269 return retval; } ! /* We no longer support the old "named-return value" extension, so get ! the return-type from the function declaration. */ ! valtype = TREE_TYPE (TREE_TYPE (current_function_decl)); gcc_assert (valtype != NULL_TREE); + result = DECL_RESULT (current_function_decl); + gcc_assert (TREE_TYPE (result) != 0); fn_returns_value_p = !VOID_TYPE_P (valtype); /* Check for a return statement with no return value in a function that's supposed to return a value. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25156
[Bug c++/25163] [3.4 Regression] g++.dg/abi/vtt1.C failure with "-funit-at-a-time"
--- Comment #2 from gdr at integrable-solutions dot net 2005-11-29 23:20 --- Subject: Re: New: [3.4 Regression] g++.dg/abi/vtt1.C failure with "-funit-at-a-time" "reichelt at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | The test g++.dg/abi/vtt1.C is failing with "-funit-at-a-time" | (or optimization "-O" or higher since this enables "-funit-at-a-time" | by default). | | GCC 4.x.y doesn't seem to be affected. | Since this behaviour can be triggered with just "-O2" I rate this as | a regression (although "-funit-at-a-time" was introduced in 3.4.0). | | Gaby, do you think that this is a showstopper for 3.4.5 or not? I think we shoulkd deal with that after 3.4.5; but I don't consider it a showstopper. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25163
[Bug c++/22573] typedef in class scope not reported by error message
--- Comment #5 from gdr at integrable-solutions dot net 2005-11-30 20:19
---
Subject: Re: typedef in class scope not reported by error message
"brad dot king at kitware dot com" <[EMAIL PROTECTED]> writes:
| Okay, if you don't consider it a bug that is fine with me. I just reported
it
| to make sure you were aware of the inconsistency. I'm changing this bug's
| status to Verified.
I don't want to leave you under the impression that your report was
dismissed as unimportant. Quite the contrary. There is a furious
debate in the user community about what the right thing should be. It
is not clear and there does not seem be a right way of doing it.
We're well aware of this issue; we're trying to do our best. I
understand not everybody is happy, but is not an issue we can make
everybody happy.
| Meanwhile I'm still a bit curious as to where in the source the
| argument's true type as written by the user is lost
| ("dereferenced"). Why is it lost only for class-scope typedefs and
| not for namespace-scope ones?
all those are good questions I don't have the answer for yet. But, if
you dig the archive (gcc-patches) you'll have a hint from a recent
patch of Mark Mitchell and another hint about the on-going debate.
| I'm somewhat familiar
| with the internals of GCC and can read the output of -fdump-translation-unit
| but I could not find the spot that loses this information. Any pointers are
| appreciated. Thanks.
-fdump-translation-unit is broken at the present; and if it did work,
it won't help you much. Search for a recent patch of Mark Mitchell
about canonicalizing types.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22573
[Bug middle-end/25181] [3.4 Regression] wrong "will never be executed" warning in switch - case block
--- Comment #4 from gdr at integrable-solutions dot net 2005-11-30 22:23 --- Subject: Re: [3.4 Regression] wrong "will never be executed" warning in switch - case block "oliverst at online dot de" <[EMAIL PROTECTED]> writes: | I forgot to meintion, that this happens with C and C++, so I guess it's a | middle-end bug!? Most probably. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25181
[Bug c++/9925] ostrstream (buf, size) << "..." does not work properly
--- Comment #15 from gdr at integrable-solutions dot net 2005-12-01 00:10 --- Subject: Re: ostrstream (buf, size) << "..." does not work properly "igodard at pacbell dot net" <[EMAIL PROTECTED]> writes: | Two bugs: with no more details, that does not help me :-) --Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9925
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #7 from gdr at integrable-solutions dot net 2005-12-02 19:23
---
Subject: Re: exception_defines.h #defines try/catch
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Confirmed. This also causes problems in normal C++ code which does:
|
| #include
|
| int f(void);
| int main(void)
| {
| try {
| f();
| }catch (a) {}
| }
|
| Without the include, you get an error but with the include, you don't which
is
| inconstaint behavior.
Indeed. But that is not changing a valid code into something else as
you claimed earlier.
The use of try/catch is part of the contract of -fno-exceptions. If a
determined programmer decides to abuse them beyond reasons, then I
believe he/she gets what he/she gets.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #6 from gdr at integrable-solutions dot net 2005-12-02 19:18 --- Subject: Re: exception_defines.h #defines try/catch I agree with Benjamin. "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | I personally would like this fixed in libstdc++ as it is changing | valid code I don't think that can be true. try and catch are C++ keyword. And exceptions are integral part of the language. As a courtesy, libstdc++ lets you use it with -fno-exceptions at the conditions that iy you use try and catch then they are rewritten into the if(0)/else stuff. | in | people's sources without them knowing it is happening to them (maybe an #undef | before the end of the header files will fix the issue). #undef at the files of the files will not fix the issue. However, it is a good suggestion of how objc can fix the issue on its side. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #8 from gdr at integrable-solutions dot net 2005-12-02 19:29 --- Subject: Re: exception_defines.h #defines try/catch "hhinnant at apple dot com" <[EMAIL PROTECTED]> writes: | --- Comment #5 from hhinnant at apple dot com 2005-12-02 19:07 --- | (In reply to comment #2) | > I'd rather you work around this in objective-c or objective c++. | | How? I'm open to suggestions. #undef them if you intend to include libstdc++ files and use try/catch with funny characters to mean something else with -fno-exceptions? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #12 from gdr at integrable-solutions dot net 2005-12-03 00:58 --- Subject: Re: exception_defines.h #defines try/catch "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | We really should not be defining keywords in the headers at all. If we define | bool somewhere to be int, we would get incorrect behavior the same way we are | getting for try/catch. But the issues are not the same. You're using try/catch with -fno-exceptions! If you used a compiler options that tells you that bool is defined to something else, that is it! -- gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #13 from gdr at integrable-solutions dot net 2005-12-03 01:02 --- Subject: Re: exception_defines.h #defines try/catch "hhinnant at apple dot com" <[EMAIL PROTECTED]> writes: | (In reply to comment #8) | > Subject: Re: exception_defines.h #defines try/catch | > | > "hhinnant at apple dot com" <[EMAIL PROTECTED]> writes: | > | > | --- Comment #5 from hhinnant at apple dot com 2005-12-02 19:07 --- | > | (In reply to comment #2) | > | > I'd rather you work around this in objective-c or objective c++. | > | | > | How? I'm open to suggestions. | > | > #undef them if you intend to include libstdc++ files and use try/catch | > with funny characters to mean something else with -fno-exceptions? | | I'm sorry, I'm just not understanding what you're suggesting. If you could | expound on your suggestion I would be most appreciative. If it helps, here is | a demo file that I would like to have work with -fno-exceptions. I'm saying that if you're intending to use try/catch and yet not want what the mean in standard C++, nor what they would mean in GNU C++ with -fno-exceptions, then you have to watch what you're doing. Meaning, in your *own* codes, you #undef try/catch. Whether it is in Cocoa.h or foobar.c, I don't care. Just take your responsability to #undef them -- because you have decided to have mean something else. I'm not inclined in seeing the libstdc++ be uglified in that direction. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #15 from gdr at integrable-solutions dot net 2005-12-03 04:20 --- Subject: Re: exception_defines.h #defines try/catch "hhinnant at apple dot com" <[EMAIL PROTECTED]> writes: | --- Comment #14 from hhinnant at apple dot com 2005-12-03 01:25 --- | (In reply to comment #13) | > Subject: Re: exception_defines.h #defines try/catch | > | > I'm saying that if you're intending to use try/catch and yet not | > want what the mean in standard C++, nor what they would mean in GNU | > C++ with -fno-exceptions, then you have to watch what you're doing. | > Meaning, in your *own* codes, you #undef try/catch. Whether it is in | > Cocoa.h or foobar.c, I don't care. Just take your responsability to | > #undef them -- because you have decided to have mean something else. | > I'm not inclined in seeing the libstdc++ be uglified in that direction. | | I see, thanks for the clarification. | | It is my understanding that gcc 4.1 supports a language called Obj C++. I don't think anybody is disputing that. It is also a simple fact that GCC documents what happens with -fno-exceptions. In | this language (and I am by no means an Obj C++ expert) you can pretty much mix | & match Obj C and C++. I have customers using Obj C++ who want to turn off C++ | exception support, but retain Obj C exception support. They can easily do so | -- unless they include a libstdc++ header. The libstdc++ headers are messing | up their ObjC @try/@catch statements. That is, libstdc++ is not supportive of | ObjC++ in this manner. No. ObjC++ is messing with itself. -fno-exceptions is documented. Either you don't want to use it, and you don't. Or you want to use it and you have to abide by what it does. | They are not trying to use C++ try/catch in a bizarre or unsupported manner. Then, why what is this PR is about in the first place? -fno-exceptions turns try/catch into macros with specified semantics. If you don't like those semantics, either you don't use -fno-exceptions, or redifine the macros to meet your needs. [...] | That is a customer-hostile solution. Trying not to abide by the rules and getting back and shouting for hostility is a joke. A sad one, Howard :-( Asking for more uglification in libstdc++ just to fix ObjC++ is a hostile solutions, if "hostile" is found to be appropriate qualification in this discussion. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #17 from gdr at integrable-solutions dot net 2005-12-04 02:54 --- Subject: Re: exception_defines.h #defines try/catch "hhinnant at apple dot com" <[EMAIL PROTECTED]> writes: [...] | But I won't apologize for being customer focused. Geeat! And people disagreeing with you on this point are not necessary customer unfocused. [...] | > No. ObjC++ is messing with itself. | | I don't know what that means. Or even how it would be relevant. ObjC++ is | what it is. If you or I don't like ObjC++, is that relevant? I'm quite disappointed you reduced this issue to liking/disliking ObjC++. If you believe that is the appropriate reduction, this is my last message on the issue. The rest clarifies what I said earlier. This issue has nothing to do with liking or disliking ObjC++, not matter how much of "hostility" or other "emotion" you would like to inject into it. ObjC++ got it wrong, it got it wrong. The place to fix it is in ObjC++. That has nothing to do with liking or disliking ObjC++. [...] | I'm honestly very confused by that response. I would not guess that it is partly because you seem to approach the issue only from ObjC++-centric point of view. This is issue is not just fixing ObjC++ by uglifying libstdc++. Those macro definitions of try/catch when -fno-exceptions have been there long before ObjC++ came in. It is not like we're suddenly changing them. The uglification you're proposing is also breaking interfaces: All user codes that worked with both -fexceptions and -fno-exceptions and used try/catch now will break. I don't think I'm prepared to accept that breakage. The fix is simple for ObjC++: #undef them if it thinks it wants both -fno-exceptions, libstdc++ headers. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug middle-end/25120] builtin *printf handlers are confused by -fexec-charset
--- Comment #12 from gdr at integrable-solutions dot net 2005-12-04 17:07 --- Subject: Re: builtin *printf handlers are confused by -fexec-charset "ghazi at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Backporting this fix to 3.4 requires also backporting the infrastructure patch | for the lang hook to_target_charset posted here: | http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00780.html Hmm, I'm tempted to leave it is as wontix on 3.4.x. Thoughts? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25120
[Bug c/25301] [3.4 regression] ICE for sizofe of incomplete type
--- Comment #2 from gdr at integrable-solutions dot net 2005-12-07 20:40
---
Subject: Re: New: [3.4 regression] ICE for sizofe of incomplete type
"reichelt at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| The testcase gcc.dg/noncompile/920923-1.c causes an ICE on the 3.4 branch.
| A reduced testcase is:
|
| ===
| typedef struct A B;
| int i = sizeof(B);
| ===
|
| bug.c:2: error: invalid application of `sizeof' to incomplete type `
| Internal compiler error: Error reporting routines re-entered.
| Please submit a full bug report, [etc.]
|
| The culprit is the code in c-objc-common.c (c_tree_printer) :
|
| case 'T':
| if (TREE_CODE (t) == TYPE_DECL)
| {
| if (DECL_NAME (t))
| n = (*lang_hooks.decl_printable_name) (t, 2);
| }
| else
| {
| t = TYPE_NAME (t);
| if (t)
| n = IDENTIFIER_POINTER (t);
| }
| break;
|
| In the above case t is a RECORD_TYPE, but TYPE_NAME (t) is a TYPE_DECL.
| So there's some logic missing to handle this case.
In general, there is a "type" problem in both C and C++ front ends.
The documentation for TYPE_NAME says that it returns a TYPE_DECL -- as
opposed to an IDENTIFIER_NODE. However, at various occasions I found
that a TYPE_NAME would return an IDENTIFIER_NODE. That is a clear bug
in both front ends ans should be hunt. Obviously, you have identified a
place where instead of correcting the problem the pretty-printer had
assumed that TYPE_NAME will always return an IDENTIFIER_NODE --
despite the documentation. I believe a proper PR should be filled so
that both front ends are cured from that confusion.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25301
[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature
--- Comment #5 from gdr at integrable-solutions dot net 2005-12-07 23:42 --- Subject: Re: std::fill_n, std::generate_n incorrect signature "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Related to PR 16505. This is the same issue as PR 16505. | | Can someone close to the standard answer the question why did they change the | return type for these functions? I think it really does not matter now -- many things changed when they got their way into the standard, for more or less obvious reasons. We've gotten a bug in libstdc++. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25304
[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature
--- Comment #9 from gdr at integrable-solutions dot net 2005-12-08 03:32 --- Subject: Re: std::fill_n, std::generate_n incorrect signature "sebor at roguewave dot com" <[EMAIL PROTECTED]> writes: | FWIW, I think Andrew makes a good point in comment #1. The algorithms really | should return the iterator, otherwise the caller may not be able to find out | the state of the iterator after the algorithm returns (e.g., when the iterator | is ostreambuf_iterator). It may not be a bad idea to open an issue (or at least | bring it up on the reflector). So do you suggest to get this PR in suspended state and get feedback from LWG? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25304
[Bug libstdc++/25306] fill_n, generate_n assume Size is modifiable
--- Comment #1 from gdr at integrable-solutions dot net 2005-12-08 03:36 --- Subject: Re: New: fill_n, generate_n assume Size is modifiable "sebor at roguewave dot com" <[EMAIL PROTECTED]> writes: | I came across this while gathering background for my post in | c++std-lib-16112. I thgought I might as well let you know in case | you think it's important enough to worry about (Size is only | required to be convertible to an integral type which doesn't mean it | needs to have the predecrement operator defined). The incorrect | return type in this test case works around bug #25304. I've come to take issue with the specification of Size. It says it is convertible to an integral type, does it does not say which. I believe the wording should be more precise -- yes, a library could conservatively take long (long) or unsigned long (long), but still that is a waste. Would you mind appending that issue to the one you raised in c++std-lib-16112? -- gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25306
[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature
--- Comment #11 from gdr at integrable-solutions dot net 2005-12-08 16:04 --- Subject: Re: std::fill_n, std::generate_n incorrect signature "sebor at roguewave dot com" <[EMAIL PROTECTED]> writes: | No, I don't. The standard is clear and most of us seem to think it's "by | design." Rather I am suggesting is that we might want to discuss with the whole | LWG changing the return type as an enhancement. I think I understand that. However, I'm looking at the pratical effect. If libstdc++ changes the return types (correcting the bug) then it will be an ABI breakage. If LWG considers and agrees on the enhancement, libstdc++ will have to change again the return types. At the end of the day we would have two ABI breakages with zero net benefit for existing libstdc++ users. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25304
[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature
--- Comment #14 from gdr at integrable-solutions dot net 2005-12-08 16:23 --- Subject: Re: std::fill_n, std::generate_n incorrect signature "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | 2- As I see the issue, it depends a lot on the actual timeframe of | the possible enhancement to the standard. I mean, if we are thinking | about C++0x, seems rather far in time. I think most of our users | would not perceive our practice as randomly going back and forward | on something. Fair enough. (At Lillehammer, we set to have x, in C++0x, a digit; so that means we're almost done by 2007. That is not far, given that LWG would not need to wait 2007 before agreeing on the issue. I was amazed to discover that CWG two two meetings to open an issue and move it to WP. LWG could do the same. Hint, hint, :-)) -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25304
[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature
--- Comment #16 from gdr at integrable-solutions dot net 2005-12-08 17:12 --- Subject: Re: std::fill_n, std::generate_n incorrect signature "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | + the more general consideration that, delivering a C++0x conforming | library certainly will involve breaking the ABI in tens of different | ways I have no trouble with that. My main concern is whether the flip flop worths it *if* we're going to change back. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25304
[Bug c++/25316] POD structures can have
--- Comment #2 from gdr at integrable-solutions dot net 2005-12-08 22:25
---
Subject: Re: New: POD structures can have
"mrs at apple dot com" <[EMAIL PROTECTED]> writes:
| A user reported that this:
|
| mrs $ cat > t98.c
| struct X {
| int a, b;
| X() : a(0), b(0) {}
| };
|
| static void f(const char *s, ...);
|
| int main()
| {
| X x;
| f("foo!", x);
| return 0;
| }
|
| works on other C++ compilers (Metroworks), but on gcc:
|
| mrs $ ./g++ -B./ -c t98.c
| t98.c: In function 'int main()':
| t98.c:11: warning: cannot pass objects of non-POD type 'struct X' through
| '...'; call will abort at runtime
|
| This, according the a reading of the standard is a POD type, no, really. :-)
Are you saying "struct X" is a POD?
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25316
[Bug c++/21581] (optimisation) Functions in anonymous namespaces should default to "hidden" visibility
--- Comment #8 from gdr at integrable-solutions dot net 2005-12-12 17:37 --- Subject: Re: (optimisation) Functions in anonymous namespaces should default to "hidden" visibility "bkoz at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | There is a feature request to assign visibility attributes to | namespaces. If this is done, then making anonymous namespaces hidden | will just be a sub-class of that work. | | That enhancement request is | | c++/21764 | | Some of the semantics need to be fleshed out concretely, and | behavior decided. I agree. Independently of the visvibility issue, GCC can make some other entities have internal linkage from the assembler/linker point of view (not C++ source point of view). -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21581
[Bug c++/21494] condensed nested namespaces
--- Comment #6 from gdr at integrable-solutions dot net 2005-12-15 03:40
---
Subject: Re: condensed nested namespaces
"bkoz at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| --- Comment #5 from bkoz at gcc dot gnu dot org 2005-12-14 17:16 ---
|
| I'm encouraged by this work!!! Great news.
|
| The reason this would be useful is that then it would be possible to use a
| single macro to represent both scope and namespace. Ie,
|
| #define ACTIVE_SCOPE
|
| works for
|
| namespace ACTIVE_SCOPE
| {
| }
|
| and explicit qualifications like
|
| ACTIVE_SCOPE::obj;
|
| Anyway.
I see what you mean. However, as ever, macro-based tehcniques just
don't play nicely with othe scope rules.
When I read the code, I don't want to be deceived. When I see
namespace ACTIVE_SCOPE { /* blah blah */ }
I really think of a named scope. Later, when I see
ACTIVE_SCOPE::obj, I really think of the obj found in ACTIVE_SCOPE
through usual rules. However, if ACTIVE_SCOPE is #defined to nothing,
then that breaks down -- the obj found is not the one from the unnamed
namespace through usual rules.
So. while I believe this work can be useful, I'm not convinced that
the macro-based techniques make a case for the extension that would
require a different set of lookup rules.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21494
