http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446
--- Comment #14 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-12-08 22:32:24 UTC ---
On Thu, 8 Dec 2011, lucier at math dot purdue.edu wrote:
Indeed, I couldn't find a place in the gcc sources where this macro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643
--- Comment #5 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-12-20 22:34:43 UTC ---
On Tue, 20 Dec 2011, sipych at gmail dot com wrote:
On platforms that do not support dynamic pre-emption of symbols an unresolved
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29997
--- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-12-22 12:53:39 UTC ---
On Thu, 22 Dec 2011, pinskia at gcc dot gnu.org wrote:
I think we encode proligue and epilogues now for all targets.
It's been done
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51730
--- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot
com 2012-01-02 13:03:35 UTC ---
On Mon, 2 Jan 2012, jakub at gcc dot gnu.org wrote:
char digs[] = 0123456789;
int xlcbug = 1 / ((digs + 5)[-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51773
--- Comment #5 from joseph at codesourcery dot com joseph at codesourcery dot
com 2012-01-06 11:47:15 UTC ---
On Fri, 6 Jan 2012, redi at gcc dot gnu.org wrote:
does glibc also define macros for alignof, true, false, bool etc. in C++ mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51773
--- Comment #7 from joseph at codesourcery dot com joseph at codesourcery dot
com 2012-01-06 15:28:16 UTC ---
On Fri, 6 Jan 2012, redi at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51773
--- Comment #6 from Jonathan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51773
--- Comment #10 from joseph at codesourcery dot com joseph at codesourcery dot
com 2012-01-06 15:51:20 UTC ---
On Fri, 6 Jan 2012, jakub at gcc dot gnu.org wrote:
I'm not sure if for -D_GNU_SOURCE we want a ::gets prototype in C++, it would
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
--- Comment #42 from joseph at codesourcery dot com joseph at codesourcery dot
com 2012-01-09 22:51:04 UTC ---
The obvious issue with C++11 attributes (such as [[noreturn]]) is that the
syntactic bindings are (or were when I last looked
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763
--- Comment #28 from joseph at codesourcery dot com joseph at codesourcery dot
com 2012-01-12 14:35:58 UTC ---
On Thu, 12 Jan 2012, rguenther at suse dot de wrote:
I think extern inlines are sadly rather common to be deprecated...
Well
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49963
--- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-08-03 18:59:33 UTC ---
I think this is a case for a function absu_hwi or similar that returns an
unsigned HOST_WIDE_INT value.
(Actually it's a case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49970
--- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-08-03 19:03:24 UTC ---
This is a bug in libtool. See bug 46607. It will need to be fixed in
upstream libtool (see bug 46607 comment 10 for what might
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973
--- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-08-04 14:38:16 UTC ---
The GCS says column numbers should start from 1 at the beginning of the
line ... Calculate column numbers assuming that space and all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50066
--- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-08-13 15:28:22 UTC ---
On Sat, 13 Aug 2011, hjl.tools at gmail dot com wrote:
--- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2011-08-13 12:09:16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50066
--- Comment #7 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-08-13 15:31:05 UTC ---
(The original code is of course valid if you use -fwrapv, so hopefully the
problem optimization does not occur in that case.)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41844
--- Comment #5 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-08-16 10:02:40 UTC ---
I don't think there's any real change from what I said in
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02242.html: the information
may
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50143
--- Comment #16 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-08-22 13:22:55 UTC ---
On Sun, 21 Aug 2011, giecrilj at stegny dot 2a.pl wrote:
Also, I don't know if you are an HTML expert, I'm not,
but I would
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50199
--- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-08-27 09:46:39 UTC ---
On Sat, 27 Aug 2011, rguenth at gcc dot gnu.org wrote:
Hmmm. Partitioning unshares string constants and I suppose ipa-cp propagates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #7 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-08-30 15:40:49 UTC ---
On Tue, 30 Aug 2011, ebotcazou at gcc dot gnu.org wrote:
The fix is to turn the check into a target check, i.e. test the target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #10 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-08-30 16:39:39 UTC ---
On Tue, 30 Aug 2011, hjl.tools at gmail dot com wrote:
The main issue is mixing input .ctors sections with .init_array sections
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50160
--- Comment #26 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-08-31 15:23:56 UTC ---
Various processors have an instruction to reverse the bit order in a word
(ARMv6T2 and later have RBIT, for example, and C6X has BITR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #12 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-08-31 15:27:44 UTC ---
On Wed, 31 Aug 2011, hjl.tools at gmail dot com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #11 from H.J
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #14 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-08-31 15:46:46 UTC ---
On Wed, 31 Aug 2011, hjl.tools at gmail dot com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #13 from H.J
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50266
--- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-09-02 13:36:20 UTC ---
I don't think there's any particular reason this initializer should need
to be folded in a particular way by the front end; I'd think
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50315
--- Comment #5 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-09-07 14:40:07 UTC ---
On Wed, 7 Sep 2011, sergos.gnu at gmail dot com wrote:
Will it be a good idea to have a twos-complement architecture hook? In case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50441
--- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-09-17 11:23:43 UTC ---
I have used the term sui generis extended type to refer to types such as
__int128 that share many properties of integer types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50470
--- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-09-21 15:03:18 UTC ---
On Wed, 21 Sep 2011, bugdal at aerifal dot cx wrote:
The sysroot features may be nice but they're not a substitute for being able
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43393
--- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-09-25 16:51:02 UTC ---
On Sun, 25 Sep 2011, paolo.carlini at oracle dot com wrote:
I'm tempted to close this, then. Comment #4 raises a C issue, however
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39813
--- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-09-29 15:40:19 UTC ---
On Wed, 28 Sep 2011, paolo.carlini at oracle dot com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39813
Paolo Carlini
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39813
--- Comment #5 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-09-29 15:48:40 UTC ---
Something is strange ... messages sent to bugs from which gcc-bugs was
removed do in fact still go to gcc-bugs anyway. So maybe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39813
--- Comment #8 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-09-29 16:51:28 UTC ---
Thanks for the explanation. I don't think you need to do anything since
the mails still get through - but seeing the address removed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50134
--- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-09-30 14:16:40 UTC ---
On Fri, 30 Sep 2011, redi at gcc dot gnu.org wrote:
I'm not sure what Do so even if the definition itself provides a prototype.
means
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50581
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-09-30 19:41:17 UTC ---
There is no possible valid use of passing arrays to va_arg.
In C99, it is never possible for an array to be passed by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50581
--- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-10-01 14:07:42 UTC ---
On Sat, 1 Oct 2011, Wolfgang at Solfrank dot net wrote:
There is no possible valid use of passing arrays to va_arg.
What makes you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50581
--- Comment #5 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-10-01 18:45:43 UTC ---
On Sat, 1 Oct 2011, Wolfgang at Solfrank dot net wrote:
Passing va_list as a function argument is generally hard, whether
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #14 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-10-05 15:19:01 UTC ---
On Wed, 5 Oct 2011, jules at gcc dot gnu.org wrote:
I don't much like the idea of using builtins for operations as fundamental
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50646
--- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-10-07 21:46:20 UTC ---
Until comparatively recently, the only thing that cared about host
endianness was decimal floating-point support. However, now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50647
--- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-10-07 21:49:58 UTC ---
In general the declarations in system.h are expected to be used only for
very archaic hosts that do not have prototypes in their system
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50647
--- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-10-07 21:54:27 UTC ---
In general, please see our bug reporting instructions. Reports of
problems building GCC are not useful without details of the build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50734
--- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-10-15 15:47:27 UTC ---
On Sat, 15 Oct 2011, rguenth at gcc dot gnu.org wrote:
This is because f can throw, you need to mark it nothrow as well in C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50773
--- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-10-18 14:49:28 UTC ---
On Tue, 18 Oct 2011, rguenth at gcc dot gnu.org wrote:
Needs -fexcess-precision=standard -m32 to trigger. libcpp does the
parsing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865
--- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-10-25 14:56:55 UTC ---
What do you think is wrong? C1X makes explicit what was intended before
then: that both a/b and a%b have undefined behavior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865
--- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-10-25 15:52:38 UTC ---
On Tue, 25 Oct 2011, jaak.randmets at cyber dot ee wrote:
What do you think is wrong? C1X makes explicit what was intended before
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865
--- Comment #5 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-10-25 15:55:28 UTC ---
Ah, I see your point - this is % 1 not % -1, so there does indeed seem to
be a bug here.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865
--- Comment #8 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-10-25 16:18:12 UTC ---
On Tue, 25 Oct 2011, jaak at ristioja dot ee wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865
--- Comment #7 from Jaak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865
--- Comment #10 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-10-25 17:13:51 UTC ---
On Tue, 25 Oct 2011, jaak at ristioja dot ee wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865
--- Comment #9 from Jaak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
--- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-02-24 15:23:33 UTC ---
This seems related to bug 40855. See also
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00652.html and the rest of
that thread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47918
--- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-02-28 20:28:27 UTC ---
On Mon, 28 Feb 2011, rguenth at gcc dot gnu.org wrote:
Also y isn't really noreturn, is it? Honza? Shouldn't non-local gotos
also
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47927
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-02-28 20:35:15 UTC ---
This (the general issue of invalid options being accepted because some
spec passes them down to some subprocess or otherwise accepts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038
--- Comment #9 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-03-01 16:39:23 UTC ---
On Tue, 1 Mar 2011, d.g.gorbachev at gmail dot com wrote:
The problem is that statics need to be mangled, so they persist
as i.1234
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47939
--- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-03-01 16:52:37 UTC ---
On Tue, 1 Mar 2011, rguenth at gcc dot gnu.org wrote:
The patch bootstrapped and tested ok. Removing
if (!flag_gen_aux_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47836
--- Comment #12 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-03-02 16:50:20 UTC ---
I do not believe any component of the GCC or src tree uses a target
libiberty. Thus, I do not think such a target libiberty should
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47953
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-03-02 16:54:10 UTC ---
I suspect this is the same as bug 46076; at least it looks related.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47977
--- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-03-04 15:35:20 UTC ---
On Fri, 4 Mar 2011, m.lazzarotto at robox dot it wrote:
My target is effectively an e500v2.
I also tried to pass -mabi=spe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47990
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-03-04 15:42:39 UTC ---
On Fri, 4 Mar 2011, rguenth at gcc dot gnu.org wrote:
In 482.sphinx3 we have code like
float foo (float x, float y)
{
return
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48014
--- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-03-07 16:45:54 UTC ---
Under POSIX, *_t is part of the implementation namespace rather than the
user namespace if any POSIX header is included. (I don't know
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44035
--- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-03-09 20:27:27 UTC ---
On Wed, 9 Mar 2011, amylaar at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44035
--- Comment #2 from Jorn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48274
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-03-24 14:01:18 UTC ---
Does the target in question define TARGET_PROMOTE_PROTOTYPES to return
true? If so, the front end is behaving as requested
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48295
--- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-03-28 10:50:44 UTC ---
On Mon, 28 Mar 2011, rguenth at gcc dot gnu.org wrote:
Btw, your testcase would be kindof invalid as you are not using the
documented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48337
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-03-29 14:51:01 UTC ---
On Tue, 29 Mar 2011, ro at gcc dot gnu.org wrote:
options.c:753:3: error: enum conversion in initialization is invalid in C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-03-29 18:50:47 UTC ---
On Tue, 29 Mar 2011, ro at gcc dot gnu.org wrote:
Running the testcase through g++ -g3 -save-temps, epsilon.ii reveals
#define
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341
--- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-03-30 15:43:53 UTC ---
On Wed, 30 Mar 2011, ro at CeBiTec dot Uni-Bielefeld.DE wrote:
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48418
--- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-04-03 11:21:27 UTC ---
It's deliberate that folding of references to const variables is now
delayed - and ideally it would move out of the front end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48524
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-04-09 11:28:33 UTC ---
Specs are an internal GCC implementation detail, subject to change
whenever convenient for implementation purposes. (Whoever put
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48524
--- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-04-10 00:27:28 UTC ---
On Sat, 9 Apr 2011, dirtyepic at gentoo dot org wrote:
Sorry, i just wanted a trivial example. The actual rule we use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48570
--- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-04-12 12:44:03 UTC ---
There are lots of optimizations that are only present for narrow strings
but logically make sense for wide strings as well (for example
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-04-12 20:18:13 UTC ---
On Tue, 12 Apr 2011, zackw at panix dot com wrote:
To the best of my knowledge, this is the only safe way (without -fwrapv) to
check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-04-12 20:52:48 UTC ---
On Tue, 12 Apr 2011, zackw at panix dot com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #2 from Zack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-04-12 21:09:53 UTC ---
On Tue, 12 Apr 2011, zackw at panix dot com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #4 from Zack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #7 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-04-12 21:16:41 UTC ---
On Tue, 12 Apr 2011, zackw at panix dot com wrote:
Addendum: what would *you* describe as the correct C idiom for
ensuring
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #9 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-04-13 12:45:35 UTC ---
On Wed, 13 Apr 2011, rguenth at gcc dot gnu.org wrote:
For the latter reasons I think the builtins should be sth like
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48685
--- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-04-21 15:36:26 UTC ---
The C front end should not depend on fold creating NON_LVALUE_EXPRs
anywhere, but I don't know if C++ has such dependencies. Where
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48696
--- Comment #13 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-04-21 15:43:27 UTC ---
On Wed, 20 Apr 2011, rguenth at gcc dot gnu.org wrote:
If gcc has forgotten the underlying type, and only looks at the bitfield
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48685
--- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-04-22 16:53:53 UTC ---
On Fri, 22 Apr 2011, jakub at gcc dot gnu.org wrote:
And it has void_type_node like its argument, which is void_type_node
COND_EXPR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760
--- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-04-25 16:02:11 UTC ---
On Mon, 25 Apr 2011, paolo.carlini at oracle dot com wrote:
A C snippet showing the issue would be:
int main()
{
float r = 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760
--- Comment #15 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-04-26 14:30:50 UTC ---
On Mon, 25 Apr 2011, john at johnmaddock dot co.uk wrote:
Sorry to be dumb, but doesn't the result of the C code violate section G
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48742
--- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-04-26 14:50:47 UTC ---
There shouldn't be nested C_MAYBE_CONST_EXPR. The code you quote
if (!in_late_binary_op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760
--- Comment #17 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-04-26 15:03:49 UTC ---
As far as I can see, the main (only?) use of imaginary types is for this
issue of constructing complex values. In addition, you need
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48742
--- Comment #5 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-04-26 15:24:13 UTC ---
On Tue, 26 Apr 2011, jakub at gcc dot gnu.org wrote:
Created attachment 24104
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48777
--- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-04-26 19:48:53 UTC ---
Indeed, empty structs in GNU C (as opposed to C++) are expected to take up
no space, and so possibly not have unique addresses.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48766
--- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-04-26 21:18:56 UTC ---
The combination -fwrapv -ftrapv is not particularly meaningful; it ought
to act exactly the same as -ftrapv (i.e. -ftrapv should
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48814
--- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-04-29 12:03:14 UTC ---
This may well be a bug, but it's the sort of case where you want an
analysis not in terms of sequence points but in terms of the more
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48816
--- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-04-29 12:08:57 UTC ---
On Fri, 29 Apr 2011, rguenth at gcc dot gnu.org wrote:
It is used in i += 3. I suppose we should ignore value-updates in
use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48814
--- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-04-29 12:13:46 UTC ---
I think the relevant wording in the C1X DIS is With respect to an
indeterminately-sequenced function call, the operation of postfix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48830
--- Comment #9 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-05-01 11:26:02 UTC ---
It's probably a good idea to test patches to subreg_get_info on an e500
target such as powerpc-eabispe. I don't *think* e500 is doing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48814
--- Comment #8 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-05-02 16:24:01 UTC ---
On Mon, 2 May 2011, rguenth at gcc dot gnu.org wrote:
The side-effects yes, but the read in count++ happens at either before
or after
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48850
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-05-03 10:45:43 UTC ---
Remarks:
* This is clearly a bug; the diagnostics given are simply wrong.
* It's not a conformance bug, as C99 permits a limit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48874
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-05-04 16:17:12 UTC ---
On Wed, 4 May 2011, jb at gcc dot gnu.org wrote:
#include stdio.h
#include complex.h
int main()
{
double _Complex a = 0.0 + I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48910
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-05-06 10:59:15 UTC ---
On Fri, 6 May 2011, Adam_5Wu at Hotmail dot com wrote:
The workaround is to stop inserting . in the system include search path
chain
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48928
--- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-05-09 09:56:56 UTC ---
On Mon, 9 May 2011, jakub at gcc dot gnu.org wrote:
Ugh, dfp is complete mess, in many places in the folder, middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48944
--- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-05-10 15:10:57 UTC ---
When I configure for this target I get:
*** This configuration is not supported in the following subdirectories:
target-libmudflap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48957
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-05-11 10:16:53 UTC ---
On Wed, 11 May 2011, psmith at gnu dot org wrote:
I think that the include-fixed directory should be associated with the
sysroot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48944
--- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-05-11 10:23:53 UTC ---
On Wed, 11 May 2011, gjl at gcc dot gnu.org wrote:
I get the following output from configure
*** This configuration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48944
--- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-05-11 13:08:05 UTC ---
On Wed, 11 May 2011, gjl at gcc dot gnu.org wrote:
I followed the recommendations in Optimize disk usage of
http://gcc.gnu.org/wiki
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49026
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-05-17 18:48:26 UTC ---
Before-and-after .s output might be useful.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49026
--- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-05-18 01:12:53 UTC ---
Should be fixed by r173845.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49081
--- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-05-20 16:03:50 UTC ---
I don't see any explanation of what you think the compiler is doing wrong.
For example, when this source file is compiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49080
--- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-05-20 16:30:51 UTC ---
It should be safe to copy the GCC copy of longlong.h into glibc; I tried
to ensure that the GCC copy is suitable for use in both places.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49138
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-05-24 14:05:58 UTC ---
On Tue, 24 May 2011, burnus at gcc dot gnu.org wrote:
The /usr/{local/,}include/fortran/ directory should be used (and searched
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49138
--- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-05-24 16:19:25 UTC ---
On Tue, 24 May 2011, burnus at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49138
--- Comment #2 from Tobias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49178
--- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-05-26 19:39:50 UTC ---
What exactly is the problem? Is the gfortran driver invoking a subprocess
with separate -l and gfortran arguments? The code in gcc.c
801 - 900 of 2017 matches
Mail list logo
