[Bug fortran/57749] -ffpe-trap=zero or invalid produces SIGFPE on complex zero ** 1e0
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 x into an integer. When x is zero and y is real, x**y is singular for y<=0, right? Also, I do not understand why I get SIGFPE on either zero or invalid -ffpe-trap suboption, but this is a lesser issue.
[Bug target/57754] Loongson 3A is MIPS64R2-compatible
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
[Bug fortran/57749] -ffpe-trap=zero or invalid produces SIGFPE on complex zero ** 1e0
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 with c complex and x real. It is not possible to make x > into an integer. > > When x is zero and y is real, x**y is singular for y<=0, right? I think you are missing the intricacies of complex arithmetics. x**y = exp (y * log(x)) has an *essential singularity* at x=0, which is the starting point of a branch cut (usually the negative real axis). See also cpow(3). The man page for pow(3) covers only real arithmetics and does not apply. > Also, I do not understand why I get SIGFPE on either zero or invalid > -ffpe-trap suboption, > but this is a lesser issue. A quick search did not turn up any result whether IEEE specifies a defined behavior for your case. Maybe you are more successful. I also could not find anything in the Fortran standard.
[Bug preprocessor/57714] Newline rendered incorrectly in output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #11 from Harald van Dijk ---
(In reply to Manuel López-Ibáñez from comment #9)
> It would be an improvement if it ignored the \ between valid tokens
> boundaries even if there is no whitespace,
Since the GCC documentation explicitly documents that no whitespace is inserted
except when necessary, as noted by David in comment #3, removing the backslash
in your example,
int foo(){\
return 0;}
would be invalid, as there was no whitespace between { and return in the
original code, and there would be after removing the backslash. It would be
valid as far as the C and C++ standards are concerned, but invalid if you also
include the documented extensions of GCC.
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 unspecified
what that code preprocesses to?
[Bug preprocessor/57714] Newline rendered incorrectly in output
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 > unspecified what that code preprocesses to? Good observation. Feel free to edit the wiki to match the documentation. Changing the documentation is less trivial, but if you think that is a better option, you could submit a patch.
[Bug fortran/57749] -ffpe-trap=zero or invalid produces SIGFPE on complex zero ** 1e0
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 roughly, but log(z) Laurent series is infinite only for z**+k. I hope to remember correctly. But exp(y*log(x)) may well be essential, however. Anyway I am not sure this is an essential (forgive the pun) reason to raise an exception Also I do not understand the different behaviour with different levels of optimization, and I confirm the a.out executable runs fine under valgrind. And the code runs fine with Intel ifort. And I really do not see how complex zero raised to a positive power should raise an exception. 2013/6/29 anlauf at gmx dot de > 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 with c complex and x real. It is not possible to make x > > into an integer. > > > > When x is zero and y is real, x**y is singular for y<=0, right? > > I think you are missing the intricacies of complex arithmetics. > > x**y = exp (y * log(x)) has an *essential singularity* at x=0, > which is the starting point of a branch cut (usually the negative > real axis). See also cpow(3). > > The man page for pow(3) covers only real arithmetics and does not apply. > > > Also, I do not understand why I get SIGFPE on either zero or invalid > > -ffpe-trap suboption, > > but this is a lesser issue. > > A quick search did not turn up any result whether IEEE specifies > a defined behavior for your case. Maybe you are more successful. > I also could not find anything in the Fortran standard. > > -- > You are receiving this mail because: > You reported the bug. >
[Bug c++/57699] Disable empty parameter list misinterpretation in libstdc++ headers when !defined(NO_IMPLICIT_EXTERN_C)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57699 Bernd Edlinger changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #3 from Bernd Edlinger --- The eCos libc headers are 100% C++ compatible, in fact the whole system is based on C++. Is this NO_IMPLICIT_EXTERN_C define set by the configure script? Should I make sure that the configure script sets NO_IMPLICIT_EXTERN_C?
[Bug preprocessor/57714] Newline rendered incorrectly in output
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.
[Bug fortran/57749] -ffpe-trap=zero or invalid produces SIGFPE on complex zero ** 1e0
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 Laurent seriesis infinite in both > directions? > z**-k and z**+k roughly, but log(z) Laurent series is infinite only for > z**+k. > I hope to remember correctly. > But exp(y*log(x)) may well be essential, however. Yes, since exp(z) has an essential singularity at complex infinity. > Anyway I am not sure this is an essential (forgive the pun) reason to raise > an exception So what should the correct result be? > Also I do not understand the different behaviour with different levels of > optimization, I think that compile-time optimization realizes that the exponent y is actually exactly a positive integer and does some simplification. At -O0, you get an evaluation by the run-time library. > and I confirm the a.out executable runs fine under valgrind. > And the code runs fine with Intel ifort. > And I really do not see how complex zero raised to a positive power should > raise an exception. Well, you actually provide a non-integer (real or complex) exponent, even if it is accidentally a positive integer.
[Bug c++/57699] Disable empty parameter list misinterpretation in libstdc++ headers when !defined(NO_IMPLICIT_EXTERN_C)
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 NO_IMPLICIT_EXTERN_C? Yes, but whether eCos defines it is not really relevant to this PR, which is about the general feature not whether it's used on a given platform or not.
[Bug testsuite/57687] FAIL: c-c++-common/cilk-plus/AN/comma_exp.c on x86_64-apple-darwin10
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?
[Bug c/57692] FAIL: c-c++-common/cilk-plus/AN/gather_scatter.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57692 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Dominique d'Humieres --- Fixed by revision 200414 Author:bviyer Date:Wed Jun 26 02:31:27 2013 UTC (3 days, 10 hours ago) Changed paths:2 Log Message: +2013-06-25 Balaji V. Iyer + + * c-c++-common/cilk-plus/AN/gather_scatter.c: Fixed a bug of stack + overflow due to size of arrays. +
[Bug testsuite/57687] FAIL: c-c++-common/cilk-plus/AN/comma_exp.c on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57687 --- Comment #9 from Dominique d'Humieres --- Fixed by revision 200554?
[Bug preprocessor/57714] Newline rendered incorrectly in output
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 macro definitions. 2. Whitespace does not need to be added to cause the visual formatting of the output to match the input. The trick is to output a backslash character in the output. Of course this would disturb clients who don't expect backslashes in their pretty-printed output. But pretty-printed output shouldn't be used for automatic translation in the first place — that is what the -P option is for. And to reconcile #2 with #1, the stringize operator and macro definition comparison need to track splices in preserved whitespace, and treat whitespace composed entirely of splices as nonexistent. That is exactly what I implemented in my own preprocessor. See edits subsequent to the one linked above. Such changes must be done internally even if you choose not to print backslashes to the final output stream. If someone wants to fix this in GCC, let this be a guide…
[Bug fortran/57749] -ffpe-trap=zero or invalid produces SIGFPE on complex zero ** 1e0
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 compile-time optimization realizes that the exponent y
> is actually exactly a positive integer and does some simplification.
> At -O0, you get an evaluation by the run-time library.
Looking at the dump tree, one find that the following is generated:
D.1825 = __builtin_cpowf (D.1824, __complex__ (1.0e+0, 0.0));
Without optimization, this is converted into a call to cpowf.
A straigtforward C example shows that the exception is generated
within libm:
#define _GNU_SOURCE
#include
#include
#include
main()
{
complex x, y, z;
x = 0.;
y = 1.;
feenableexcept (FE_DIVBYZERO | FE_OVERFLOW | FE_INVALID);
z = cpowf (x, y);
printf("z = %f + %f * i\n", creal(z), cimag(z));
}
(gdb) run
Starting program: /home/anlauf/a.out
Program received signal SIGFPE, Arithmetic exception.
0xb7f98ea3 in clogf () from /lib/libm.so.6
Missing separate debuginfos, use: zypper install
glibc-debuginfo-2.14.1-14.27.1.i686
(gdb) where
#0 0xb7f98ea3 in clogf () from /lib/libm.so.6
#1 0xb7f9a4d4 in cpowf () from /lib/libm.so.6
#2 0x080485a2 in main () at check-cpow.c:12
That's with glibc-2.14.1.
[Bug preprocessor/57714] Newline rendered incorrectly in output
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://code.google.com/p/c-plus/source/detail?r=2849f0f6d0677ed2679e39aad2c85e87f9b7ebd4 .
[Bug c++/57746] rejected valid specialization of member function of class template (I think)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57746 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler --- According to the standard in general a definition is also a declaration ([basic.def] p2 "A declaration is a definition unless it declares a function without specifying the function’s body (8.4), [..]"), therefore [temp.explicit] applies here as well. I think that GCC is incorrect in not rejecting both cases, because the wording clearly includes a "static data member of a class template" (This error still exists in gcc 4.9 trunk). I also think that the meaning of the code is well-defined only for C++11, because in C++03 the concept of an explicit instantiation declaration did not exist.
[Bug preprocessor/57714] Newline rendered incorrectly in output
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.
#define ID(x) x
#define STR(x) STR_(x)
#define STR_(x) #x
STR(ID(1)ID(2))ID(3)ID(4)
preprocesses to
"12"3 4
No space is inserted between the 1 and 2, because the C standard does not allow
that. No space is inserted between "12" and 3, because no space was present in
the input and no space is required. A space is inserted between 3 and 4 because
the preprocessed output would be misinterpreted otherwise.
> 2. Whitespace does not need to be added to cause the visual formatting of the
> output to match the input. The trick is to output a backslash character in
> the output.
A trailing backslash at the end of a line after preprocessing is a syntax error
and is treated as such by GCC. What you suggest requires running the result
through the preprocessor again in order to be able to compile the result. Note
that
int main() {
ret\
urn 0;
}
is perfectly valid, but
#define ID(x) x
int main() {
ID(ret)ID(\)
urn 0;
}
is not. If these become undistinguishable after preprocessing, it is impossible
to diagnose the syntax error, and that diagnostic is required.
[Bug c++/57757] New: CPP extra inserted whitespace needs to be reviewed for C++11 user-defined literals
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
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: harald at gigawatt dot nl
This invalid code
void operator"" _u(const char *, __SIZE_TYPE__) { }
#define ID(x) x
int main() {
ID("")ID(_u);
}
is correctly rejected with
$ g++ -std=c++11 -c test.cc
test.cc: In function ‘int main()’:
test.cc:5:12: error: expected ‘;’ before ‘_u’
ID("")ID(_u);
^
test.cc:3:15: note: in definition of macro ‘ID’
#define ID(x) x
^
as the "" and _u are separate tokens. However, with -save-temps, it gets
accepted incorrectly, because in the preprocessor output, "" and _u are joined
as ""_u.
$ g++ -std=c++11 -save-temps -c test.cc
(no output)
The preprocessor needs to insert a space between "" and _u in C++11 mode. For C
mode and C++03 mode, whitespace is not required, and as the documentation
states that GCC does not insert whitespace unless required, the preprocessor
output should only change in C++11 mode.
Modifying the example slightly, it's also possible to get something that
compiles without -save-temps, and gets rejected with it:
#define ID(x) x
void operator ID("")ID(_u)(const char *, __SIZE_TYPE__) { }
int main() {
""_u;
}
$ g++ -std=c++11 -c test.cc
$ g++ -std=c++11 -save-temps -c test.cc
test.cc:3:6: error: missing space between ‘""’ and suffix identifier
void operator ID("")ID(_u)(const char *, __SIZE_TYPE__) { }
^
test.cc: In function ‘int main()’:
test.cc:6:3: error: unable to find string literal operator ‘operator"" _u’
""_u;
^
[Bug fortran/34547] NULL(): Fortran 2003 changes, accepts invalid, ICE on invalid
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 #0, namely integer, allocatable :: i(:) print *, NULL(i) end gives an ICE with 4.8.1 and trunk (4.9) pr34547_1.f90:2:0: internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6423 print *, NULL(i) It compiles with 4.7.3, and gives the reported error with 4.6.4.
[Bug preprocessor/57714] Newline rendered incorrectly in output
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 just no way a user would handle it all properly. GCC avoids inserting whitespace except where "necessary," where a token boundary would be invisible, but tokenizing has gotten harder than it was. My preprocessor doesn't bother with any artificial whitespace. Pretty mode is for user display only, and robust processing needs out-of-band non-text data.
[Bug fortran/54852] Bogus(?) warnings when compiling gfortran.dg/bind_c_vars.f90 gfortran.dg/bind_c_vars_driver.c with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54852 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-29 CC||jh at suse dot cz Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Still present at revision 200557.
[Bug c++/57757] CPP extra inserted whitespace needs to be reviewed for C++11 user-defined literals
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 from Jakub Jelinek --- That should be fixed by the r200563 changes committed today for the trunk. Not sure if a backport of that is planned or not though.
[Bug c++/57757] CPP extra inserted whitespace needs to be reviewed for C++11 user-defined literals
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 actually fix the issue my testcase
demonstrates, it merely makes it so that my testcase no longer demonstrates my
issue. I'll attempt to come up with a different testcase.
[Bug fortran/57553] Valid use of STORAGE_SIZE rejected, bad error message for invalid use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57553 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-29 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres --- > TODO: The following message for invalid code should be improved. ... Confirmed.
[Bug fortran/45417] DEALLOCATE: No error when deallocating a target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45417 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-29 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Still present at revision 200557.
[Bug c++/57757] CPP extra inserted whitespace needs to be reviewed for C++11 user-defined literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57757
--- Comment #3 from Harald van Dijk ---
Updated testcase, tested with :
#define ID(x) x
extern ID("C")void exit(int);
int main() { exit(0); }
This should be accepted, and is, except when -save-temps is used:
$ ~/gcc-run/bin/g++ -std=c++11 -c test.cc
$ ~/gcc-run/bin/g++ -std=c++11 -save-temps -c test.cc
test.cc:2:8: error: expected unqualified-id before ‘STRING_USERDEF’ token
extern ID("C")void exit(int);
^
test.cc: In function ‘int main()’:
test.cc:3:20: error: ‘exit’ was not declared in this scope
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 PARTICULAR PURPOSE.
Using sources from git mirror, commit 801070f5acc11e86fd587b583ebe2ce900ab7a5d,
corresponding to svn rev 200565.
[Bug fortran/48244] iso-c-binding support missing on NetBSD (with patch)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48244 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-29 CC||cato at df dot lth.se Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Is there still maintainers/users of NetBSD?
[Bug fortran/52176] Valgrind complains about some realloc on assignment to unallocated LHS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52176 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-29 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- What should I do with this PR?
[Bug target/54407] FAIL: 30_threads/condition_variable/54185.cc execution test program timed out on powerpc-apple-darwin9 and x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54407 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-29 Ever confirmed|0 |1 --- Comment #19 from Dominique d'Humieres --- > I posted this patch back in Oct as... > > http://gcc.gnu.org/ml/libstdc++/2012-10/msg00111.html > > Mike wanted a comment about an associated radar which doesn't exist. > As far as I know this bug was fixed in the pthread rewrites for darwin11 > and later. Could someone commit the patch?
[Bug tree-optimization/52267] a&~N where N has all the bits set up till a specific point can be folded to ((unsigned)a) < N
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52267 Jorn Wolfgang Rennecke changed: What|Removed |Added CC||amylaar at gcc dot gnu.org --- Comment #8 from Jorn Wolfgang Rennecke --- (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 because of the sheer amount of values in this program. Here is a summary of the failing subtests / iteration counts: f2,f1: i == 6,7 f4,f5,f3: i == 13,15,16,24,25,31 f7,f8,f6: i == 10..12,23 f11,f9: i == 11,13,15,24,25,31 f12,f10: i == 11,13,15,24,25,26,31 f17: i == 12,13 f21: i == 21,22,38..45
[Bug tree-optimization/52267] a&~N where N has all the bits set up till a specific point can be folded to ((unsigned)a) < N
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52267 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug c++/57757] CPP extra inserted whitespace needs to be reviewed for C++11 user-defined literals
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 one-sentence description, but won't because I unfortunately expect copyright assignment would be a problem.)
[Bug tree-optimization/57719] [4.8/4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
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 from Mikael Pettersson --- (In reply to Zhendong Su from comment #2) > test #2: wrong code from both gcc trunk and 4.8 at -O3 in 32-bit mode only: The wrong-code for test #2 also started with r196174.
[Bug c++/57758] New: gcc accepts incorrect in-class brace initializers
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: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lundberj at gmail dot com
In summary, having a class member in-class copy-construct from itself (!)
compiles without warning when curly-brace syntax is used.
The result is that the class invariants are never established. The following
code is accepted:
#include
struct C{
C()=delete;
C(const C& other): x(other.x+1){}
int x=10;
};
struct D{
C c0{c0}; // << -- compiles without warning
//C c1{c1}; // << -- correctly rejected
};
int main(){
D d;
std::cout << d.c0.x << std::endl; // prints 1
}
You already get the point. Similarly, these definitions of C also compiles, and
the printed value of x is 0 in both cases.
struct C{
int x=10;
C(float,float){}
};
struct C{
int x=10;
};
Using the following definition I get an un-initialized reference: x == 1412476
:
struct C{
C(const C& other): z(other.z),x(other.x){}
int z=10;
int & x{z};
};
This seems like something that would be good to detect.
Using class C{}; is correctly rejected (with 'too many initializers for ‘C’').
[Bug tree-optimization/57719] [4.8/4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
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.
[Bug tree-optimization/52267] a&~N where N has all the bits set up till a specific point can be folded to ((unsigned)a) < N
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 because of the sheer amount of values in this program.
>
> Here is a summary of the failing subtests / iteration counts:
> f2,f1: i == 6,7
> f4,f5,f3: i == 13,15,16,24,25,31
> f7,f8,f6: i == 10..12,23
> f11,f9: i == 11,13,15,24,25,31
> f12,f10: i == 11,13,15,24,25,26,31
> f17: i == 12,13
> f21: i == 21,22,38..45
I've tried to shift/mask the values / tests to fit 16 bit ints while keeping
to the spirit of the tests and leaving the int >= 32 bit case unchanged,
but the various leading bits, / masking, and 16 bit value comparisons
are just to intertwined for this to make any sense.
I think we should simply restrict the test to target { ! int16 } .
[Bug tree-optimization/57719] [4.8/4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
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.
[Bug c++/57758] gcc accepts incorrect in-class brace initializers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57758 Paolo Carlini changed: What|Removed |Added Keywords||diagnostic CC||paolo.carlini at oracle dot com --- Comment #1 from Paolo Carlini --- Frankly, I doubt this issue adds new information beyond what we have got already in Bugzilla, eg PR52167 & co.
[Bug tree-optimization/57701] Incorrect optimisation of inlined function with inline assembly when cross-compiling
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 #3 from rennis at gmx dot com --- Richard, do you have any information on how to specify the side-effects? Any tips or guesses on how you would go about it in this situation? I'm having the same problem as sqweek (we're both trying to build inferno-os, a 32-bit application, on archlinux 64-bit). I'm far out of my realm here. I've played with assembly before, but never done much with inline assembly. Thanks, Rob
[Bug target/54407] FAIL: 30_threads/condition_variable/54185.cc execution test program timed out on powerpc-apple-darwin9 and x86_64-apple-darwin10
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.
[Bug fortran/54384] gfortran memory leaks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54384 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-29 Ever confirmed|0 |1 --- Comment #11 from Dominique d'Humieres --- Considering the number of commits, this PR can probably marked as confirmed.
[Bug fortran/50149] loader error with source containing common blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50149 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #5 from Dominique d'Humieres --- Closing as WORKSFORME.
[Bug libfortran/48961] EXECUTE_COMMAND_LINE(WAIT=.false.) fails on MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48961 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-29 Ever confirmed|0 |1 --- Comment #13 from Dominique d'Humieres --- >From comment #12 > So it seems the current implementation is not so bad after all. Could this PR be closed as FIXED?
[Bug fortran/50516] gfortran must detect illegal statements in a block data (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50516 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-29 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Still there at revision 200557.
[Bug fortran/52274] [Meta-bug] Fortran translation related issues: Typos and more
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52274 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-29 Ever confirmed|0 |1
[Bug fortran/57598] [Coarray,caf] Add FPE-Summary printing (floating-point exception) for STOP/ERROR STOP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57598 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-29 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Has not this bug fixed by revision 200147? Author:burnus Date:Mon Jun 17 07:48:21 2013 UTC (12 days, 13 hours ago) Changed paths:19 (showing only 10; show all) Log Message: 2013-06-17 Tobias Burnus * gfortran.h (gfc_option_t): Add fpe_summary. * gfortran.texi (_gfortran_set_options): Update. * invoke.texi (-ffpe-summary): Add doc. * lang.opt (ffpe-summary): Add flag. * options.c (gfc_init_options, gfc_handle_option): Handle it. (gfc_handle_fpe_option): Renamed from gfc_handle_fpe_trap_option, also handle fpe_summary. * trans-decl.c (create_main_function): Update _gfortran_set_options call. 2013-06-17 Tobias Burnus * libgfortran.h (compile_options_t) Add fpe_summary. (get_fpu_except_flags): New prototype. * runtime/compile_options.c (set_options, init_compile_options): Handle fpe_summary. * runtime/stop.c (report_exception): New function. (stop_numeric, stop_numeric_f08, stop_string, error_stop_string, error_stop_numeric): Call it. * config/fpu-387.h (get_fpu_except_flags): New function. * config/fpu-aix.h (get_fpu_except_flags): New function. * config/fpu-generic.h (get_fpu_except_flags): New function. * config/fpu-glibc.h (get_fpu_except_flags): New function. * config/fpu-glibc.h (get_fpu_except_flags): New function. * configure.ac: Check for fpxcp.h. * configure: Regenerate. * config.h.in: Regenerate.
[Bug fortran/57096] Allocatable variable is not behaved as expected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57096 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-29 Ever confirmed|0 |1 --- Comment #5 from Dominique d'Humieres --- >From comment #1 > Confirmed with current trunk.
[Bug fortran/56471] Program crashes when allocating a derived type with an allocatable component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56471 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-29 Ever confirmed|0 |1
[Bug fortran/56596] Invalid read of size 4 gfortran.dg/class_array_7.f03
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 --- Comment #5 from Dominique d'Humieres --- *** Bug 55482 has been marked as a duplicate of this bug. ***
[Bug fortran/55482] gfortran.dg/class_array_7.f03 execution failures with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55482 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Dominique d'Humieres --- Fixed by the patch for PR57456, r199528, duplicate of pr56956. *** This bug has been marked as a duplicate of bug 56596 ***
[Bug fortran/52279] Fortran translation issues issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52279 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-29 Ever confirmed|0 |1
[Bug target/57754] Loongson 3A is MIPS64R2-compatible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57754 Steven Bosscher changed: What|Removed |Added Target||mips64 Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-29 CC||rsandifo at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/57758] gcc accepts incorrect in-class brace initializers
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.
Re: [Bug fortran/48244] iso-c-binding support missing on NetBSD (with patch)
> --- 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
[Bug fortran/48244] iso-c-binding support missing on NetBSD (with patch)
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 ago, so I am not allowed to commit anything... :( /Krister
[Bug testsuite/57687] FAIL: c-c++-common/cilk-plus/AN/comma_exp.c on x86_64-apple-darwin10
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 from Balaji V. Iyer --- This should be fixed in the recent check-in I did with Jason Merrill's changes. Thanks, Balaji V. Iyer.
[Bug fortran/57749] -ffpe-trap=zero or invalid produces SIGFPE on complex zero ** 1e0
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 power should be zero. No exceptions raised. I do not know if this is correct, but it looks reasonable to me. Computing complex zero**1 delivers (0.0,0.0), but complex zero**1.0 raises an exception. How strange. This is reading the base and exponent, no optimization involved. As in: complex zero read *,zero,i,x print *,zero,i,x print *,zero**i print *,zero**x When both numbers are complex, the standards (F95, F2003, and F2008) state that "the value of the operation x1**x2 is the principal value of x1 raised to x2". Does it help? When aimag(x2) is zero what is the principal value? I cannot believe that zero**1e0 is a singularity. The Intel ifort compiler delivers the "reasonable" result, it even goes beyond that and computes zero**zero as (1.0,0.0)! And I still believe the result should not depend on the optimization level. Note that compiling without -ffpe-trap the result with default optimization, -O0, is ( 0., -0.), higher optimizations deliver ( 0., 0.). Another mystery.
