--- Comment #4 from joseph at codesourcery dot com 2009-08-25 16:58 ---
Subject: Re: [4.5 Regression] Syntax error: Unterminated
quoted string
On Tue, 25 Aug 2009, rwild at gcc dot gnu dot org wrote:
> --- Comment #3 from rwild at gcc dot gnu dot org 2009-08-25 16
--- Comment #5 from joseph at codesourcery dot com 2009-08-26 18:59 ---
Subject: Re: [4.5 regression] libgfortran fails to
build on Solaris 10+: '_Imaginary_I' undeclared
On Wed, 26 Aug 2009, ro at techfak dot uni-bielefeld dot de wrote:
> I don't have access to
--- Comment #7 from joseph at codesourcery dot com 2009-08-27 16:38 ---
Subject: Re: [4.5 regression] libgfortran fails to
build on Solaris 10+: '_Imaginary_I' undeclared
On Thu, 27 Aug 2009, ro at techfak dot uni-bielefeld dot de wrote:
> What I don't fully
--- Comment #2 from joseph at codesourcery dot com 2009-09-02 14:39 ---
Subject: Re: [4.5 regression] Revision 151313 caused many
regressions on trunk
On Wed, 2 Sep 2009, jakub at gcc dot gnu dot org wrote:
> Only pr40753.c is a regression, the rest are new tests. And guality te
--- Comment #28 from joseph at codesourcery dot com 2009-09-03 11:04
---
Subject: Re: can not build gcc 4.4.1 on Snow Leopard
Mac OS X 10.6
On Thu, 3 Sep 2009, howarth at nitro dot med dot uc dot edu wrote:
> Mike,
> Regarding passing -m32 within the x86_64 host case,
--- Comment #7 from joseph at codesourcery dot com 2009-09-05 11:35 ---
Subject: Re: [4.5 Regression] FAIL:
gcc.dg/matrix/matrix-2.c scan-ipa-dump-times matrix-reorg "Flattened 2
dimensions" 1
On Sat, 5 Sep 2009, rguenth at gcc dot gnu dot org wrote:
> It's glibc
--- Comment #16 from joseph at codesourcery dot com 2009-09-07 17:24
---
Subject: Re: stddef.h assumes machinee/ansi.h defines
_ANSI_H_
On Mon, 7 Sep 2009, prlw1 at cam dot ac dot uk wrote:
> I just got stuck with this again: wondered why a NetBSD-5.99.15/i386 box with
> gc
--- Comment #3 from joseph at codesourcery dot com 2009-09-09 20:52 ---
Subject: Re: New: [4.5 Regression] Failed to bootstrap
On Wed, 9 Sep 2009, hjl dot tools at gmail dot com wrote:
> We aren't consistent where to report gcc bugs:
>
> [...@gnu-31 src-tr
--- Comment #2 from joseph at codesourcery dot com 2009-09-11 15:51 ---
Subject: Re: [LTO] Bootstrap failed on RHEL5/ia32 and
RHEL5/ia64
On Fri, 11 Sep 2009, rguenth at gcc dot gnu dot org wrote:
> You need newer libelf.
This should result in a configure error, not an error a
--- Comment #2 from joseph at codesourcery dot com 2009-09-15 13:04 ---
Subject: Re: correct types for OpenBSD targets
Please send patches to gcc-patches.
http://gcc.gnu.org/contribute.html
(I believe existing testcases already cover consistency of these types.)
If sorting out type
--- Comment #1 from joseph at codesourcery dot com 2009-09-16 12:00 ---
Subject: Re: New: C99 basic character set
String and character literals may contain characters from the source
character set that are not members of the basic source character set.
See the syntax for c-char
--- Comment #41 from joseph at codesourcery dot com 2009-09-20 21:04
---
Subject: Re: [4.5 Regression] major regressions on
*-apple-darwin10 at -m64 caused by r147995
On Sun, 20 Sep 2009, howarth at nitro dot med dot uc dot edu wrote:
> If so, we can't just apply an
--- Comment #6 from joseph at codesourcery dot com 2009-09-20 21:08 ---
Subject: Re: [4.5 Regression] ICE: tree check: expected
integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:5259
There is no backtrace in this bug or any statement of the point in such a
backtrace at which
--- Comment #10 from joseph at codesourcery dot com 2009-09-20 21:23
---
Subject: Re: [4.5 Regression] ICE: tree check: expected
integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:5259
Where (backtrace) did the C_MAYBE_CONST_EXPR get created? Where
(backtrace) did the
--- Comment #3 from joseph at codesourcery dot com 2009-09-23 11:11 ---
Subject: Re: New: libffi fails to build with -mfloat-abi=softfp
On Wed, 23 Sep 2009, doko at ubuntu dot com wrote:
> ../../../src/libffi/src/arm/sysv.S: Assembler messages:
> ../../../src/libffi/src/arm/
--- Comment #4 from joseph at codesourcery dot com 2009-09-23 11:28 ---
Subject: Re: libffi fails to build with -mfloat-abi=softfp
The __ARM_ARCH__ settings in this file are also out of date (no handling
of __ARM_ARCH_6T2__, __ARM_ARCH_6M__, __ARM_ARCH_7__, __ARM_ARCH_7A__
--- Comment #1 from joseph at codesourcery dot com 2009-09-30 14:14 ---
Subject: Re: New: Unnecessary uninitialized warning
In C, enums may hold any value of the underlying integer type, so this
warning seems correct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41519
--- Comment #4 from joseph at codesourcery dot com 2009-10-04 12:17 ---
Subject: Re: New: -m32 causes an ICE when the object files
were compiled with 64bit
While this case should give a sensible error (not an ICE), linking an
object built with a 32-bit compiler with no special
--- Comment #7 from joseph at codesourcery dot com 2009-10-05 19:46 ---
Subject: Re: Misnamed hpp files in gcc-4.4.1.tar.bz2
from ftp://gd.tuwien.ac.at
On Mon, 5 Oct 2009, davine at poczta dot onet dot pl wrote:
> of 2 files and no real corruption? (the build was successful)
--- Comment #1 from joseph at codesourcery dot com 2009-10-06 00:10 ---
Subject: Re: New: Bad .comm directive
On Mon, 5 Oct 2009, danglin at gcc dot gnu dot org wrote:
> The directive is:
>
> .comm gnu_lto_v1,1,1
>
> This apparently comes from here:
>
--- Comment #1 from joseph at codesourcery dot com 2009-10-06 15:59 ---
Subject: Re: New: Cannot build LTO without stdint.h
On Tue, 6 Oct 2009, sje at cup dot hp dot com wrote:
> After the LTO merge GCC will not bootstrap on HPPA HP-UX because this system
> does not have st
--- Comment #12 from joseph at codesourcery dot com 2009-10-09 12:58
---
Subject: Re: plugin-api.h unconditionally includes stdint.h
On Fri, 9 Oct 2009, ro at techfak dot uni-bielefeld dot de wrote:
> --- Comment #10 from ro at techfak dot uni-bielefeld dot de 2009-10-09
&
--- Comment #16 from joseph at codesourcery dot com 2009-10-09 14:44
---
Subject: Re: plugin-api.h unconditionally includes stdint.h
On Fri, 9 Oct 2009, ro at techfak dot uni-bielefeld dot de wrote:
> > gold supports non-ELF hosts (or will once Andrew Pinski's
--- Comment #13 from joseph at codesourcery dot com 2009-10-09 19:42
---
Subject: Re: Massive failures in parallel test mode
On Fri, 9 Oct 2009, chris at bubblescope dot net wrote:
> LD_LIBRARY_PATH doesn't exist on Mac. Usually linking libraries together 'just
--- Comment #10 from joseph at codesourcery dot com 2009-10-14 02:27
---
Subject: Re: Evaluate complex math functions at
compile-time
On Wed, 14 Oct 2009, ghazi at gcc dot gnu dot org wrote:
> Support for the "arc" functions is done in the mpc svn repository whi
--- Comment #9 from joseph at codesourcery dot com 2009-10-19 16:44 ---
Subject: Re: FAIL: gcc.dg/tree-prof/bb-reorg.c compilation,
-fprofile-use -D_PROFILE_USE
On Mon, 19 Oct 2009, rearnsha at gcc dot gnu dot org wrote:
> I don't think there should be such notes on ARM du
--- Comment #10 from joseph at codesourcery dot com 2009-10-19 16:46
---
Subject: Re: FAIL: gcc.dg/tree-prof/bb-reorg.c compilation,
-fprofile-use -D_PROFILE_USE
On Mon, 19 Oct 2009, rearnsha at gcc dot gnu dot org wrote:
> Created an attachment (id=18826)
--> (http://gcc.g
--- Comment #2 from joseph at codesourcery dot com 2009-10-25 17:43 ---
Subject: Re: libstdc++.so.6.0.14-gdb.py is not an ELF
file
Some people dislike a few warnings from ldconfig. I think having this as
a text file alongside the library is much better than alternative
suggestions
--- Comment #1 from joseph at codesourcery dot com 2009-10-29 15:47 ---
Subject: Re: New: Translation time Floating Point precision
is too small
On Thu, 29 Oct 2009, tydeman at tybor dot com wrote:
> The following code fails on (at least) Intel x86/x87 systems running Li
--- Comment #2 from joseph at codesourcery dot com 2009-11-04 19:42 ---
Subject: Re: New: __attribute__ ((visibility)) weird with
functions returning pointers
Visibility attributes are in the nature of storage class specifiers and so
should be placed at the start of the declaration
--- Comment #2 from joseph at codesourcery dot com 2009-11-09 13:16 ---
Subject: Re: ICE on invalid dereferencing of void *
On Mon, 9 Nov 2009, rguenth at gcc dot gnu dot org wrote:
> the C standard doesn't claim dereferencing a void pointer is invalid, so
> the gimpli
--- Comment #2 from joseph at codesourcery dot com 2009-11-11 23:35 ---
Subject: Re: server not respond
This is probably a duplicate of bug 41343 (it's reported against a trunk
version more than a month old).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42012
--- Comment #3 from joseph at codesourcery dot com 2009-11-12 03:01 ---
Subject: Re: Make -mfloat-gprs=double the default when
compiling for powerpc-linux-gnuspe target
Note that there are more than just e500 processors with the SPE
functionality; for example, at least some e200
--- Comment #19 from joseph at codesourcery dot com 2009-11-12 17:20
---
Subject: Re: String not extracted for translation
On Thu, 12 Nov 2009, pearly dot zhao at oracle dot com wrote:
> Run "make gcc.pot" in objdir/gcc/ can extract both branches of this
> conditio
--- Comment #21 from joseph at codesourcery dot com 2009-11-13 13:26
---
Subject: Re: String not extracted for translation
On Fri, 13 Nov 2009, pearly dot zhao at oracle dot com wrote:
> (In reply to comment #19)
> > Subject: Re: String not extracted for translation
&g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46489
--- Comment #4 from joseph at codesourcery dot com 2010-12-20 15:43:37 UTC ---
On Mon, 20 Dec 2010, amylaar at gcc dot gnu.org wrote:
> When using gcc, using -dD, I can auto-generate a headerfile tm-poison.h which
> poisons all macro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46489
--- Comment #6 from joseph at codesourcery dot com 2010-12-20 17:42:46 UTC ---
On Mon, 20 Dec 2010, amylaar at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46489
>
> --- Comment #5 from Jorn Wolfgang Rennecke
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47047
--- Comment #1 from joseph at codesourcery dot com 2010-12-23 12:16:37 UTC ---
On Thu, 23 Dec 2010, joerg at netbsd dot org wrote:
> The patch is the version included in NetBSD against the system gcc, it can be
> updated if necessary.
W
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47047
--- Comment #3 from joseph at codesourcery dot com 2010-12-23 16:13:53 UTC ---
On Thu, 23 Dec 2010, joerg at britannica dot bec.de wrote:
> > On Thu, 23 Dec 2010, joerg at netbsd dot org wrote:
> >
> > > The patch is th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47081
--- Comment #3 from joseph at codesourcery dot com 2010-12-28 19:44:02 UTC ---
On Tue, 28 Dec 2010, pinskia at gcc dot gnu.org wrote:
> I don't know if generator files should be have translated error messages.
> Unlike other progra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47091
--- Comment #2 from joseph at codesourcery dot com 2010-12-29 11:20:39 UTC ---
arm-netbsd appears unmaintained. Apart from the desirability of moving
NetBSD to EABI, there's a clear bogosity in arm/netbsd.h I noticed a while
back:
/* Alt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47096
--- Comment #2 from joseph at codesourcery dot com 2010-12-29 11:22:07 UTC ---
There are more i686-interix3 problems than that; even without -Werror a
cross to that target won't build in my experience.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47103
--- Comment #1 from joseph at codesourcery dot com 2010-12-29 11:26:09 UTC ---
On Wed, 29 Dec 2010, goeran at uddeborg dot se wrote:
> In gcc/config/i386/i386.opt there are multi-line descriptions of the options
> mvzeroupper and mdi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47107
--- Comment #1 from joseph at codesourcery dot com 2010-12-29 14:07:50 UTC ---
This is a bug in config.gcc; it should just accept i[34567]86 like other
x86 targets, not ix86.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47091
--- Comment #4 from joseph at codesourcery dot com 2010-12-29 16:11:10 UTC ---
On Wed, 29 Dec 2010, rguenth at gcc dot gnu.org wrote:
> (and a possible list of targets to deprecate).
I gave my own suggestions for deprecations in
&l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47109
--- Comment #1 from joseph at codesourcery dot com 2010-12-30 22:02:44 UTC ---
My preferred fix for this would be to eliminate the TARGET_VERSION macro
completely. I really don't think it's useful for targets to have this
special ve
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47119
--- Comment #2 from joseph at codesourcery dot com 2010-12-31 20:03:27 UTC ---
On Fri, 31 Dec 2010, amylaar at gcc dot gnu.org wrote:
> There are a lot more problems with this port. Here is a patch that makes
> the port sort-of build when
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47119
--- Comment #4 from joseph at codesourcery dot com 2010-12-31 21:17:40 UTC ---
On Fri, 31 Dec 2010, amylaar at gcc dot gnu.org wrote:
> C and C++ frontends each have their own, different versions of these
> functions, but then these fun
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47137
--- Comment #9 from joseph at codesourcery dot com 2011-01-03 13:54:28 UTC ---
Does reverting the r168407 commit and instead applying Jie's first patch
from http://gcc.gnu.org/ml/gcc/2010-12/msg00517.html fix all the present
problems?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47145
--- Comment #6 from joseph at codesourcery dot com 2011-01-03 16:11:45 UTC ---
On Mon, 3 Jan 2011, ktietz at gcc dot gnu.org wrote:
> The issue here is AC_CHECK_FILE, which is documented to not work for
> cross-compiling scenario. By rep
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47150
--- Comment #5 from joseph at codesourcery dot com 2011-01-03 16:22:17 UTC ---
On Mon, 3 Jan 2011, jakub at gcc dot gnu.org wrote:
> The problem is in save_expr called by convert_to_complex when converting
> non-COMPLEX_EXPR _Complex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47170
--- Comment #1 from joseph at codesourcery dot com 2011-01-04 17:39:49 UTC ---
On Tue, 4 Jan 2011, ettl.martin at gmx dot de wrote:
> during a check of gcc's sources with the static code analysis tool cppcheck
> (http://sourceforge.n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42445
--- Comment #3 from joseph at codesourcery dot com 2011-01-06 16:02:11 UTC ---
I know nothing about what the issue is supposed to be here or what is or
is not supposed to be in COLLECT_GCC_OPTIONS or how COLLECT_GCC_OPTIONS is
used.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42445
--- Comment #5 from joseph at codesourcery dot com 2011-01-06 16:47:48 UTC ---
On Thu, 6 Jan 2011, hjl.tools at gmail dot com wrote:
> GCC driver translates -march=native to something cc1/cc1plus
> knows. Since -march=native isn'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47229
--- Comment #2 from joseph at codesourcery dot com 2011-01-09 14:47:10 UTC ---
See discussions on gcc-patches in Aug/Sep 2010 of patches that attempted
to add such drivers but duplicated too much code instead of carefully
refactoring with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47249
--- Comment #1 from joseph at codesourcery dot com 2011-01-10 18:00:22 UTC ---
On Mon, 10 Jan 2011, hjl.tools at gmail dot com wrote:
>Target Milestone|--- |4.6.0
This is not a 4.6 regression, though it may b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46037
--- Comment #7 from joseph at codesourcery dot com 2011-01-10 22:47:26 UTC ---
On Mon, 10 Jan 2011, hubicka at gcc dot gnu.org wrote:
> so it seems that re-running process_options on darwin somehow leads to this
> change. Adding Joseph
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076
--- Comment #17 from joseph at codesourcery dot com 2011-01-11 15:28:56 UTC ---
On Tue, 11 Jan 2011, rguenth at gcc dot gnu.org wrote:
> I don't think we should add hacks like that. Either the type signatures
> are compatible for the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47297
--- Comment #1 from joseph at codesourcery dot com 2011-01-14 17:04:30 UTC ---
On Fri, 14 Jan 2011, mateusz at loskot dot net wrote:
> In spite of the fact the behavior is undefined, I suspect the intent
> is to be consistent (which appe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46607
--- Comment #6 from joseph at codesourcery dot com 2011-01-24 23:29:27 UTC ---
That would not be an appropriate use of WONTFIX; WONTFIX is for cases such
as bugs in a target that has been removed. It's a clear bug in libtool;
SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47390
--- Comment #2 from joseph at codesourcery dot com 2011-01-24 23:37:39 UTC ---
On Fri, 21 Jan 2011, rguenth at gcc dot gnu.org wrote:
> Joseph - 4.5 handled -export-dynamic by passing it through to the linker
> (not exactly sure why).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47400
--- Comment #1 from joseph at codesourcery dot com 2011-01-24 23:45:31 UTC ---
This would be a testsuite issue; the tests require a locale using the
ASCII character set. Where (in several .exp files) the code does
# Many hosts now default to a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47409
--- Comment #5 from joseph at codesourcery dot com 2011-01-25 00:00:37 UTC ---
I think we should respect volatile on fields, and not use memcpy/memmove
for assignment of volatile structs or structs with volatile fields (at
least not for the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46607
--- Comment #8 from joseph at codesourcery dot com 2011-01-25 16:55:18 UTC ---
On Tue, 25 Jan 2011, rwild at gcc dot gnu.org wrote:
> But there is a good reason to relink on ELF: uninstalled libraries and
> executables get DT_RPATH e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47409
--- Comment #8 from joseph at codesourcery dot com 2011-01-25 17:04:24 UTC ---
On Tue, 25 Jan 2011, rguenth at gcc dot gnu.org wrote:
> do we really want to blow up code-size (and compile-time) for
>
> struct {
> volatile i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46607
--- Comment #10 from joseph at codesourcery dot com 2011-01-27 17:47:12 UTC ---
On Thu, 27 Jan 2011, aoliva at gcc dot gnu.org wrote:
> This could bring an improvement for a few platforms, but it wouldn't solve the
> problme in g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47549
--- Comment #4 from joseph at codesourcery dot com 2011-01-31 20:51:56 UTC ---
The involvement of -save-temps makes me suspect the same underlying issue
as bug 21521.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31827
--- Comment #13 from joseph at codesourcery dot com 2011-02-01 17:00:26 UTC ---
Out of interest, does compiling GCC with -fsplit-stack help avoid this
problem? This obviously has limitations at present regarding supported
hosts, and the need
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47390
--- Comment #4 from joseph at codesourcery dot com 2011-02-08 01:35:49 UTC ---
On Tue, 8 Feb 2011, dirtyepic at gentoo dot org wrote:
> looks like some packages also use --export-dynamic, which just flat out fails
> now.
>
> x8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47390
--- Comment #7 from joseph at codesourcery dot com 2011-02-08 16:54:19 UTC ---
On Tue, 8 Feb 2011, rguenth at gcc dot gnu.org wrote:
> Hm, I see. The -e LINK_COMMAND_SPEC isn't documented in invoke.texi
> "Link Options", d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47751
--- Comment #2 from joseph at codesourcery dot com 2011-02-15 17:51:18 UTC ---
-mfloat-gprs=double or -mspe without -mabi=spe does not correspond to any
standard ABI variant and is very likely to be broken.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781
--- Comment #4 from joseph at codesourcery dot com 2011-02-17 18:24:25 UTC ---
On Thu, 17 Feb 2011, mark-gcc at glines dot org wrote:
> I'd like to request a finer grained means of control. A syntactical element
> (builtin/pragm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47794
--- Comment #1 from joseph at codesourcery dot com 2011-02-18 02:24:58 UTC ---
This commit should not affect anything not using -Ofast, and I get
identical before/after code with -m32 when I tested vla-1.c. Could you
give example source and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
--- Comment #2 from 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. libstdc++ support for ex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47918
--- Comment #2 from 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 prevent nor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47927
--- Comment #1 from 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 them) is
what my 4.7 patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43038
--- Comment #9 from 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 instead. Rea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47939
--- Comment #6 from 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 && (TYPE_QU
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47836
--- Comment #12 from 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 be built
or installed by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47953
--- Comment #1 from 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 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, with no difference in the output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47990
--- Comment #1 from 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 ((int)(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57371
--- Comment #1 from joseph at codesourcery dot com ---
On Wed, 22 May 2013, glisse at gcc dot gnu.org wrote:
> int f(int i){
> return (double)i != 0;
> }
>
> compiled with -Ofast (I don't think -ffast-math matters) keeps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #9 from joseph at codesourcery dot com ---
I think this is invalid, because the assignment that changes the current
union member doesn't go through the union type (cf. DR#236).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57675
--- Comment #2 from joseph at codesourcery dot com ---
N1399 has a detailed analysis of issues with complex multiply and divide
in C99. There was no consensus to adopt requirements in that detail, but
N1496 was adopted with a more minimal fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57725
--- Comment #4 from joseph at codesourcery dot com ---
I'd say that in the presence of those extensions, it should be considered
unspecified whether pointers to distinct objects at the same address
compare equal or not.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57725
--- Comment #6 from joseph at codesourcery dot com ---
On Thu, 27 Jun 2013, jbeulich at novell dot com wrote:
> How that? How is code supposed to find out then?
Why does the code want to find out? If it's using these extensions it&#
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57725
--- Comment #8 from joseph at codesourcery dot com ---
On Thu, 27 Jun 2013, jbeulich at novell dot com wrote:
> That's why I gave the example of where this is coming from - the code
> obviously
> wants to be able to determine wh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740
--- Comment #10 from joseph at codesourcery dot com ---
On Thu, 27 Jun 2013, pinskia at gcc dot gnu.org wrote:
> No it does not. Or rather there have not been an ABI change in libstdc++
> since
> 3.4. If you compile with the oldest d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57814
--- Comment #1 from joseph at codesourcery dot com ---
On Wed, 3 Jul 2013, janis at gcc dot gnu.org wrote:
> Several of the tests added for PR46728 fail for powerpc-none-eabi and
> powerpc-none-eabispe. The tests all use -mpowerpc-gpo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
--- Comment #13 from joseph at codesourcery dot com ---
For the RTL operations and optabs, we have CLZ_DEFINED_VALUE_AT_ZERO and
CTZ_DEFINED_VALUE_AT_ZERO, but as noted in the documentation they do not
refer to definedness for the built-in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34352
--- Comment #5 from joseph at codesourcery dot com ---
If multi-line descriptions are to be disallowed (and it does appear they
are outside the .opt format as presently documented in options.texi), then
opt-read.awk should generate an error on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57949
--- Comment #6 from joseph at codesourcery dot com ---
I'm not expert on the 64-bit ABI; the Power.org ABI TSC never really got
onto doing anything with the 64-bit ABI, although nominally it's in scope.
The only Freescale peculiarity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #2 from joseph at codesourcery dot com ---
There are no errno issues - this is an exact zero result, not underflow.
But I'm not confident that MPFR follows all the Annex F special cases for
infinities and NaNs (and even
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #7 from joseph at codesourcery dot com ---
An example of MPC not following all the Annex G special cases is that
catanh (1 + i0) is specified in Annex G to return Inf + i0 with
divide-by-zero exception, but at least with my MPC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58005
--- Comment #3 from joseph at codesourcery dot com ---
Such an optimization can increase code size (well, the total size of
string constants in the program) if the same format string is used with
many different arguments, so it may not always
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #11 from joseph at codesourcery dot com ---
On Sat, 27 Jul 2013, glisse at gcc dot gnu.org wrote:
> Yeah, any of those. I was inspired by glibc, which has for instance:
>
> double
> __fdim (double x, double y)
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016
--- Comment #1 from joseph at codesourcery dot com ---
I don't know whether Andrew intends stdatomic.h to go in GCC or glibc, but
in any case I consider this a duplicate of bug 53769, which in turn I
don't really consider a useful bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016
--- Comment #4 from joseph at codesourcery dot com ---
__STDC_VERSION__ describes *intent* of command-line options (as regards
differences between standard versions, to the extent that those are
implemented). This is the same principle that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016
--- Comment #7 from joseph at codesourcery dot com ---
__STDC_NO_THREADS__ is defined in glibc's stdc-predef.h because it
describes combination compiler and library properties.
The correct fix for atomics for 4.9 will be to implement them
401 - 500 of 2027 matches
Mail list logo
