http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
--- Comment #16 from Jakub Jelinek ---
Defining the value at this point would mean that we'd need to generate
slower/larger code on various targets (including i386/x86_64 when not
targetting the really most recent CPUs only) and possibly create ne
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
--- Comment #15 from Ondrej Bilka ---
On Thu, Jul 04, 2013 at 07:46:07PM +, glisse at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
>
> --- Comment #14 from Marc Glisse ---
> (In reply to Jakub Jelinek from comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792
--- Comment #7 from Jack Howarth ---
(In reply to Jack Howarth from comment #6)
My mistake in mixing host_configargs and build_configargs. The following patch
works fine…
Index: configure.ac
===
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57827
Bug ID: 57827
Summary: compiler segmentation fault
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792
--- Comment #6 from Jack Howarth ---
(In reply to Jack Howarth from comment #5)
The same change of adding --with-sysroot=\"`xcrun --show-sdk-path`\" to
build_configargs also fails when fix_includes tries to find /usr/include.
Strangely, adding --
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792
--- Comment #5 from Jack Howarth ---
I am really surprised the following change if insufficient to replace manually
passing…
--with-sysroot="`xcrun --show-sdk-path`"
to configure on the command line for darwin13...
Index: configure.ac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792
Jack Howarth changed:
What|Removed |Added
Summary|fixincludes doesn't honor |toplevel configure should
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,
> th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38634
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57826
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57826
Bug ID: 57826
Summary: "Internal compiler error: Error reporting routines
re-entered" with -Weffc++ and weak_ptr
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57779
François Dumont changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57825
--- Comment #7 from Tomasz Kamiński ---
> No, this was a different problem and it became fixed. Your example code
> works fine gcc 4.9.0 20130616 (experimental) (I do know this, because I
> recently completed the implementation of std::function fo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57825
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
--- Comment #14 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #12)
> Not all CPUs that have defined behavior for 0 define it to the precision
> though, and even on i?86 it is undefined even when using lzcnt/tzcnt on
> older CPUs.
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57825
--- Comment #5 from Daniel Krügler ---
(In reply to Paolo Carlini from comment #3)
> Daniel, which library testcases did we commit?!? ;) Crazy.
During an intermediate state we had bug 57388 which prevented for some time the
proper specialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57825
--- Comment #4 from Daniel Krügler ---
(In reply to Tomasz Kamiński from comment #2)
> Propably this is also causing the problem with the standard library
> is_function and is_member function traits, because they cannot be
> implemented correclty.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57825
--- Comment #3 from Paolo Carlini ---
Daniel, which library testcases did we commit?!? ;) Crazy.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57825
--- Comment #2 from Tomasz Kamiński ---
Propably this is also causing the problem with the standard library is_function
and is_member function traits, because they cannot be implemented correclty.
Example:
struct A
{
void f_n() {}
void f_l()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57825
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
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 funct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57825
Bug ID: 57825
Summary: Template specialization for ref qualified member
pointers
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Prior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57821
--- Comment #2 from Paolo Carlini ---
Wondering if c++/57793 has also something to do with this (sorry if I'm saying
something stupid, I didn't really study it in any detail)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
--- Comment #12 from Jakub Jelinek ---
Not all CPUs that have defined behavior for 0 define it to the precision
though, and even on i?86 it is undefined even when using lzcnt/tzcnt on older
CPUs.
Even the libgcc routines provide various return val
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
--- Comment #11 from Marc Glisse ---
(In reply to dean from comment #10)
> this is unfortunate really -- the newer LZCNT/TZCNT instructions on x86
> explicitly return 8*sizeof(type) for input of zero
Same as the power cntlz* instructions. And in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
--- Comment #10 from dean at arctic dot org ---
On Thu, 4 Jul 2013, jakub at gcc dot gnu.org wrote:
> I'm not 100% sure about CLZ/CTZ in the patch, because it could return any
> value
> for argument of 0, but as we document it as undefined behavi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57820
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57824
--- Comment #1 from Jakub Jelinek ---
Created attachment 30459
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30459&action=edit
gcc49-pr57824.patch
Untested fix. Seems to work on these testcases without -save-temps, with
-save-temps the lin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792
--- Comment #3 from Jack Howarth ---
(In reply to Bruce Korb from comment #2)
> Paolo did the config stuff, with Kaveh's help.
> However, Jack Howarth may be in a better position to
> make a patch since I do not have an Apple development
> system.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57824
Bug ID: 57824
Summary: Raw string literals not handled correctly in macro
arguments or deferred pragmas
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57823
--- Comment #3 from vincenzo Innocente ---
indeed
float * bar3() {
const float * a = (float*) malloc(4*128);
const float * b = (float*) malloc(4*128);
float * c = (float*) malloc(4*128);
a = (const float*)__builtin_assume_aligned (a, 16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792
Bruce Korb changed:
What|Removed |Added
CC||bonzini at gnu dot org,
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57823
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #2 fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52267
--- Comment #10 from Jorn Wolfgang Rennecke ---
The patch to fix the testsuite is here:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00079.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57823
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35862
--- Comment #24 from Tobias Burnus ---
Created attachment 30458
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30458&action=edit
Proof of concept (.c file)
Proof of concept test case (in C, tested on x86-64-gnu linux with libc 2.17).
[Someh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57823
Bug ID: 57823
Summary: restrict qualifier non effective with pointer returned
by new
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57822
Bug ID: 57822
Summary: I/O: "(g0)" wrongly prints "E+"
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007
--- Comment #22 from Andreas Schwab ---
In glibc newlocale(0,"C",0) is cheap and doesn't need to be cached.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007
--- Comment #21 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #20)
> has to obtain the locale with newlocale(..., "C",...) - and later should
> free it with freelocale.
Respectively, __newlocale and __freelocale for pre-POSIX-200
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007
--- Comment #20 from Tobias Burnus ---
And yet another possibility: Some systems (like Darwin) have strtod_l (etc.)
which takes a locale argument. GLIBC seems to have it only as weak symbol but
offers __strtod_l.
Looking againt at GCC's C++ comp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57821
--- Comment #1 from Jorn Wolfgang Rennecke ---
avr faces an additional issue in c/c-typeck:set_init_index, where the
designator value is converted to bitsizetype; that is 24 bit PSImode for
avr.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792
Jack Howarth changed:
What|Removed |Added
Summary|--with-native-system-header |fixincludes doesn't honor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57663
--- Comment #6 from Sebastien Bardeau ---
(In reply to Dominique d'Humieres from comment #5)
> > Well, I am "only" a Fortran programmer, I have no idea of how
> > the GNU compilers are written...
>
> Obviously you know how to build gfortran, so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57819
--- Comment #2 from Jakub Jelinek ---
Created attachment 30457
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30457&action=edit
gcc49-pr57819-2.patch
Alternative that touches only i386 backend.
In theory I think the simplify-rtx.c and combi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57663
--- Comment #5 from Dominique d'Humieres ---
> Well, I am "only" a Fortran programmer, I have no idea of how
> the GNU compilers are written...
Obviously you know how to build gfortran, so can either try to revert r167779
or apply r171236. Howev
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57819
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007
--- Comment #19 from Tobias Burnus ---
Seemingly, g++ prefers to unset the locale. Namely,
libstdc++-v3/config/locale/generic/c_locale.cc has:
// Assumes __s formatted for "C" locale.
char* __old = setlocale(LC_ALL, 0);
const si
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57821
Bug ID: 57821
Summary: 'array is too large' error is missing when sizetype
overflows
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57663
--- Comment #4 from Sebastien Bardeau ---
(In reply to Dominique d'Humieres from comment #3)
> > Is there any chance that someone has a look to this bug?
>
> No, but you can do it yourself.
Well, I am "only" a Fortran programmer, I have no idea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
Jakub Jelinek changed:
What|Removed |Added
Attachment #30453|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022
--- Comment #28 from Daniel Krügler ---
(In reply to Paolo Carlini from comment #27)
Yes.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022
Paolo Carlini changed:
What|Removed |Added
Status|SUSPENDED |NEW
--- Comment #27 from Paolo Carlini -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54998
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54998
--- Comment #1 from Paolo Carlini ---
This is fixed in mainline. I'm adding the testcase and closing the bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35862
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #23
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57820
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57820
Bug ID: 57820
Summary: Can't initialize a constexpr object with inline
initialization
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57793
--- Comment #5 from Paolo Carlini ---
Note that something like this ICEs the C compiler too:
struct A { _Bool a : 1; _Bool b : 1; };
struct B
{
unsigned char c[0x4000];
unsigned char d[0x4ff0];
struct A e;
};
void *foo (struct B *p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57793
--- Comment #4 from Paolo Carlini ---
Thanks Jakub.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57818
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 57818, which changed state.
Bug 57818 Summary: A strange template output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57818
What|Removed |Added
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57818
Paolo Carlini changed:
What|Removed |Added
Keywords|wrong-code |
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57819
Bug ID: 57819
Summary: Suboptimal shift patterns
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57815
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57818
Paolo Carlini changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55914
Paolo Carlini changed:
What|Removed |Added
CC||lb-guilherme at live dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57817
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367
Bug 54367 depends on bug 57817, which changed state.
Bug 57817 Summary: g++ crashes on handling variadic template sizeof inside
lambda funcion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57817
What|Removed |Add
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57808
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57818
Bug ID: 57818
Summary: A strange template output
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57793
Jakub Jelinek changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
CC|
75 matches
Mail list logo
