http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749
--- Comment #2 from Vittorio Zecca ---
I believe -O0 is the default optimization level, so it is important.
Of course the code I sent you is a fragment from a much larger program,
kind of c**x with c complex and x real. It is not possible to make
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57754
--- Comment #1 from Heiher ---
Created attachment 30409
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30409&action=edit
Patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749
--- Comment #3 from Harald Anlauf ---
(In reply to Vittorio Zecca from comment #2)
> I believe -O0 is the default optimization level, so it is important.
>
> Of course the code I sent you is a fragment from a much larger program,
> kind of c**x w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #12 from Manuel López-Ibáñez ---
(In reply to Harald van Dijk from comment #11)
> Could you either not suggest that the current behaviour is a bug (even if it
> is a minor one) in the FAQ, or change the documentation so that it is
> un
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749
--- Comment #4 from Vittorio Zecca ---
I am happy to refresh my complex analysis study of long ago.
The singularity of log(x) in zero is not essential.
Essential singularity means the Laurent seriesis infinite in both
directions?
z**-k and z**+k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57699
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #13 from Harald van Dijk ---
Sure. I have no strong preference on the matter, and have changed the wiki.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749
--- Comment #5 from Harald Anlauf ---
(In reply to Vittorio Zecca from comment #4)
> I am happy to refresh my complex analysis study of long ago.
> The singularity of log(x) in zero is not essential.
Right.
> Essential singularity means the Laur
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57699
--- Comment #4 from Jonathan Wakely ---
(In reply to Bernd Edlinger from comment #3)
> Is this NO_IMPLICIT_EXTERN_C define set by the
> configure script?
It's set by headers under gcc/config/
> Should I make sure that the
> configure script sets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57687
--- Comment #8 from Dominique d'Humieres ---
Seems to have been fixed between revisions 200407 and 200557. Could someone
confirm, narrow the range, or point to the revision before I close this PR as
FIXED?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57692
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57687
--- Comment #9 from Dominique d'Humieres ---
Fixed by revision 200554?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #14 from David Krauss ---
Harald's comment #10 is almost accurate, but for two things:
1. Actually the C standard does care whether whitespace is added. Whitespace is
visible in the result of stringizing, and when comparing duplicate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749
--- Comment #6 from Harald Anlauf ---
(In reply to Harald Anlauf from comment #5)
> (In reply to Vittorio Zecca from comment #4)
> > Also I do not understand the different behaviour with different levels of
> > optimization,
>
> I think that comp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #15 from David Krauss ---
Corrections to previous: Harald's comment is #11, and I meant to refer to the
commits in my repo from
http://code.google.com/p/c-plus/source/detail?r=d462b650c355b606545158f4da7365180b699752
up through
http://
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57746
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #16 from Harald van Dijk ---
(In reply to David Krauss from comment #14)
> 1. Actually the C standard does care whether whitespace is added.
You're right for stringizing, but GCC already takes care to treat that as a
special case.
#d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57757
Bug ID: 57757
Summary: CPP extra inserted whitespace needs to be reviewed for
C++11 user-defined literals
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34547
--- Comment #8 from Dominique d'Humieres ---
> It looks like it was fixed in 4.7.0 with the following error message
>
> Error: NULL intrinsic at (1) in data transfer statement requires MOLD=
Confirmed, however compiling the second test in comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #17 from David Krauss ---
Yes, my preprocessor classifies the backslash-after-preprocessing as a
whitespace token. I simply don't intend to make textual preprocessing output.
With raw strings, UCNs, and user-defined literals, there's j
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54852
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57757
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=57757
--- Comment #2 from Harald van Dijk ---
Thanks for the pointer. That commit looks like it fixes a different issue: that
looks like it's about allowing
void operator""_u(const char *, __SIZE_TYPE__) { }
which was previously rejected. It does not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57553
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45417
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
int main() { exit(0); }
^
$ ~/gcc-run/bin/g++ --version
g++ (GCC) 4.9.0 20130629 (experimental)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTIC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48244
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52176
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54407
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52267
Jorn Wolfgang Rennecke changed:
What|Removed |Added
CC||amylaar at gcc dot gnu.org
--- C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52267
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57757
--- Comment #4 from Harald van Dijk ---
It looks like this is a simple matter of adding an extra case in
libcpp/lex.c:cpp_avoid_paste, returning true for (CPP_STRING, CPP_NAME) when
UDLs are enabled. (I'd attach a working patch instead of a brief
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57719
Mikael Pettersson changed:
What|Removed |Added
CC||mikpe at it dot uu.se
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57758
Bug ID: 57758
Summary: gcc accepts incorrect in-class brace initializers
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57719
--- Comment #4 from Mikael Pettersson ---
(In reply to Zhendong Su from comment #2)
> test #3: wrong code from gcc trunk (but not gcc 4.8) at -O3 in 32-bit mode
> only:
The wrong-code for test #3 started with r198121.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52267
--- Comment #9 from Jorn Wolfgang Rennecke ---
(In reply to Jorn Wolfgang Rennecke from comment #8)
> (In reply to Georg-Johann Lay from comment #7)
>
> > I just rediced the test case to find this thinko; I don't know if there are
> > more becaus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57719
--- Comment #5 from Mikael Pettersson ---
(In reply to Zhendong Su from comment #2)
> test #4: wrong code from gcc trunk (but not gcc 4.8) at -O3 in both 32-bit
> and 64-bit modes:
The wrong-code for test #4 also started with r198121.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57758
Paolo Carlini changed:
What|Removed |Added
Keywords||diagnostic
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57701
rennis at gmx dot com changed:
What|Removed |Added
CC||rennis at gmx dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54407
--- Comment #20 from Paolo Carlini ---
Commit *what*? Please add a link to something actually OKed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54384
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50149
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48961
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50516
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52274
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57598
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57096
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56471
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56596
Dominique d'Humieres changed:
What|Removed |Added
CC||howarth at nitro dot med.uc.edu
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55482
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52279
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57754
Steven Bosscher changed:
What|Removed |Added
Target||mips64
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57758
--- Comment #2 from Johan Lundberg ---
Yes. I'm sorry, it's almost word-for-word identical to 48483.
> --- Comment #1 from Dominique d'Humieres ---
> Is there still maintainers/users of NetBSD?
There are still users. But my paperwork is not in order since I
changed employer some years ago, so I am not allowed to commit
anything... :(
/Krister
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48244
--- Comment #2 from krister.walfridsson at gmail dot com ---
> --- Comment #1 from Dominique d'Humieres ---
> Is there still maintainers/users of NetBSD?
There are still users. But my paperwork is not in order since I
changed employer some years
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57687
Balaji V. Iyer changed:
What|Removed |Added
CC||bviyer at gmail dot com
--- Comment #10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749
--- Comment #7 from Vittorio Zecca ---
Looking at the source code for cpowf, it computes x**y straightly as
exp(y*log(x)),
no check on y or x.
I am not happy with that, because I expect that complex zero raised to any
(real or integer) positive p
58 matches
Mail list logo
