[Bug c++/57682] New: Uniform initialization syntax rejected in function-try-block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57682 Bug ID: 57682 Summary: Uniform initialization syntax rejected in function-try-block Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: webrown.cpp at gmail dot com Created attachment 30342 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30342&action=edit Source file demonstrating issue Compiling via: g++-mp-4.9 -std=gnu++1y -c bug.cc Using version: g++-mp-4.9 (MacPorts gcc49 4.9-20130616_0) 4.9.0 20130616 (experimental) Using paren's to initialize a data member will compile successfully, but using braces in their place produces a diagnostic. Define/undefine the OOPS macro in the attachment to reproduce failure/success.
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 --- Comment #8 from Allan McRae --- I really have no idea what I am looking for... but adding a breakpoint at linemap_add I see (reason, file): LC_ENTER "foo.c" LC_RENAME "" LC_ENTER "/usr/include/stdc-predef.h" LC_LEAVE 0x0 LC_RENAME "foo.c" <- correct output printed here LC_LEAVE 0x0 LC_ENTER "foo.c" LC_RENAME "" LC_ENTER "foo.h" LC_LEAVE 0x0 LC_ENTER "/usr/include/stdc-predef.h" LC_RENAME "foo.c" LC_LEAVE 0x0 <- incorrect output printed here LC_LEAVE 0x0 So it looks like it is not leaving "/usr/include/stdc-predef.h" at the right time so the wrong thing is being renamed?
[Bug target/52483] SH Target: Loads from volatile memory leave redundant sign/zero extensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52483 --- Comment #4 from Oleg Endo --- Loads from volatile mems have been fixed on 4.9 trunk. While working on it I noticed that stores to volatile mems have basically the same issue. I'll try to come up with a fix for that, too. http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=200350 PR target/52483 * config/sh/predicates.md (general_extend_operand): Invoke general_movsrc_operand for memory operands. (general_movsrc_operand): Allow reg+reg addressing, do not use general_operand for memory operands. PR target/52483 * gcc.target/sh/pr52483-1.c: New. * gcc.target/sh/pr52483-2.c: New. * gcc.target/sh/pr52483-3.c: New. * gcc.target/sh/pr52483-4.c: New. * gcc.target/sh/pr52483-5.c: New.
[Bug c++/57682] Uniform initialization syntax rejected in function-try-block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57682
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-06-23
Ever confirmed|0 |1
--- Comment #1 from Paolo Carlini ---
This is enough:
#define OOPS
struct Class
{
Class(int func)
try
#ifdef OOPS
: f{ func } { }
#else
: f( func ) { }
#endif
catch( ... ) { }
private:
int f;
};
[Bug bootstrap/57683] New: Parallel build failure: generated prerequisite header not built in time (insn-opinit.h)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57683 Bug ID: 57683 Summary: Parallel build failure: generated prerequisite header not built in time (insn-opinit.h) Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: nix at binaryboy dot net Created attachment 30343 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30343&action=edit Patch to generate header insn-opinit.h early Bootstrap failure on parallel build of gcc cross compiler for ARM target. Single job build unaffected and verified to work. In my particular circumstance, the first pass builds successfully however the second pass, which builds libgcc as well, fails due to above reason. Build error: In file included from /gcc/lra-constraints.c:127: /gcc/optabs.h:24:25: error: insn-opinit.h: No such file or directory Reason: Prerequisite header file 'gcc/insn-opinit.h' not generated before being required. Solution: add 'insn-opinit.h' to 'generated_files' variable in 'gcc/Makefile.in' where prerequisite files are declared (obvious it should be there) - see attached patch. System: Darwin host.local 12.4.0 Darwin Kernel Version 12.4.0: Wed May 1 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64 (OS X 10.8.4) System GCC: gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) Build GCC: gcc version 4.8.1 (crosstool-NG hg+unknown-20130621.174606) Target Arch: ARM
[Bug bootstrap/57683] Parallel build failure: generated prerequisite header not built in time (insn-opinit.h)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57683 Nicolas Hannekum changed: What|Removed |Added CC||nix at binaryboy dot net Severity|normal |major
[Bug c++/57682] Uniform initialization syntax rejected in function-try-block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57682
--- Comment #2 from Paolo Carlini ---
Something is already going wrong as early as
cp_parser_save_member_function_body: at line #22818 the whole
function-try-block is not properly handled in case of uniform initialization
syntax, apparently because the closed '}' of 'f{ func }' is confused with the
closed '}' of 'f( func ) { }', and the former at variance with the latter
isn't followed by 'catch'.
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
--- Comment #18 from Manuel López-Ibáñez ---
(In reply to David Binderman from comment #17)
> (In reply to Daniel Marjamäki from comment #7)
> > In my experience this type of check is really noisy if there is a warning
> > for every fall through.
> >
> > I recommend that the warning is written only if the fall through cause
> > redundant or bad behaviour. such as:
> >
> > switch (foo) {
> > case 1: x = y; // <- redundant assignment
> > case 2: x = z;
> > };
>
> I'd be happy with gcc warning for this kind of problem.
>
> This specific case should be easier to catch than the
> general case.
In fact, this case is the same outside a switch:
x = y;
x = z;
I think this could be useful, but it will depend a lot on the implementation.
So we need someone to implement it ;-)
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-06-23
Ever confirmed|0 |1
--- Comment #9 from Manuel López-Ibáñez ---
(In reply to Allan McRae from comment #8)
> I really have no idea what I am looking for... but adding a breakpoint at
> linemap_add I see (reason, file):
>
> LC_ENTER "foo.c"
> LC_RENAME ""
> LC_ENTER "/usr/include/stdc-predef.h"
> LC_LEAVE 0x0
> LC_RENAME "foo.c"
> <- correct output printed here
> LC_LEAVE 0x0
>
> LC_ENTER "foo.c"
> LC_RENAME ""
> LC_ENTER "foo.h"
> LC_LEAVE 0x0
> LC_ENTER "/usr/include/stdc-predef.h"
> LC_RENAME "foo.c"
> LC_LEAVE 0x0
> <- incorrect output printed here
> LC_LEAVE 0x0
>
> So it looks like it is not leaving "/usr/include/stdc-predef.h" at the right
> time so the wrong thing is being renamed?
It seems a probable cause for this bug. Can you track where the return paths
differ?
Does
LC_ENTER "/usr/include/stdc-predef.h"
happen through the same functions in both cases?
and the LC_LEAVE 0x0 just afterwards?
Perhaps there is a missing LC_LEAVE or perhaps the order between
LC_RENAME "foo.c"
LC_LEAVE 0x0
should be reversed.
Strangely, I still cannot reproduce this:
manuel@gcc10:~$ ~/test1/200330/install/bin/gcc -imacros foo.h foo.c
foo.c: In function ‘main’:
foo.c:1:21: error: expected expression before ‘}’ token
int main() { return }
^
manuel@gcc10:~$ ~/test1/200330/install/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/manuel/test1/200330/install/bin/gcc
COLLECT_LTO_WRAPPER=/home/manuel/test1/200330/install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/manuel/test1/src/configure
--prefix=/home/manuel/test1/./200330/install
--enable-languages=c,c++,objc,fortran,ada,obj-c++
Thread model: posix
gcc version 4.9.0 20130622 (experimental) [trunk revision 195333] (GCC)
Are you sure you don't have some local arch-linux patches? Have you tried
directly downloading the svn version?
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 Manuel López-Ibáñez changed: What|Removed |Added Status|NEW |WAITING --- Comment #10 from Manuel López-Ibáñez --- Sorry, I didn't intend to confirm it until someone else can reproduce it.
[Bug c++/57684] New: [c++11] Lambda is not convertible to std::function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57684
Bug ID: 57684
Summary: [c++11] Lambda is not convertible to std::function
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bluescarni at gmail dot com
Created attachment 30344
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30344&action=edit
Code snippet demonstrating the problem.
A specific setup with CRTP pattern and a static unordered_map member in the
base class is preventing conversion from a lambda expression to an
std::function. The problem is reproduced in the attached code snippet. The
error produced by GCC 4.8.1 is:
main.cpp: In function ‘int main()’:
main.cpp:20:3: error: no matching function for call to
‘std::function::function(main()::__lambda0)’
});
^
main.cpp:20:3: note: candidates are:
In file included from main.cpp:1:0:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2255:2: note:
template std::function<_Res(_ArgTypes
...)>::function(_Functor)
function(_Functor);
^
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2255:2: note:
template argument deduction/substitution failed:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2230:7: note:
std::function<_Res(_ArgTypes ...)>::function(std::function<_Res(_ArgTypes
...)>&&) [with _Res = derived; _ArgTypes = {const derived&}]
function(function&& __x) : _Function_base()
^
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2230:7: note:
no known conversion for argument 1 from ‘main()::__lambda0’ to
‘std::function&&’
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2433:5: note:
std::function<_Res(_ArgTypes ...)>::function(const std::function<_Res(_ArgTypes
...)>&) [with _Res = derived; _ArgTypes = {const derived&}]
function<_Res(_ArgTypes...)>::
^
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2433:5: note:
no known conversion for argument 1 from ‘main()::__lambda0’ to ‘const
std::function&’
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2210:7: note:
std::function<_Res(_ArgTypes ...)>::function(std::nullptr_t) [with _Res =
derived; _ArgTypes = {const derived&}; std::nullptr_t = std::nullptr_t]
function(nullptr_t) noexcept
^
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2210:7: note:
no known conversion for argument 1 from ‘main()::__lambda0’ to
‘std::nullptr_t’
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2203:7: note:
std::function<_Res(_ArgTypes ...)>::function() [with _Res = derived; _ArgTypes
= {const derived&}]
function() noexcept
^
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2203:7: note:
candidate expects 0 arguments, 1 provided
(Sorry for not being able to reduce the test case further, but I was able to
reproduce the problem only by pulling in std::unordered_map. GCC 4.7.3 and
Clang++ 3.3 both compile the snippet without errors.)
The problem disappears if one replaces the static member definition with one of
the commented lines or even if one replaces the existing main() body with this:
std::function foo([](const derived &d) {
return d;
});
I.e., by changing the std::function to return void instead of derived.
[Bug fortran/52413] Incorrect behavior of FRACTION when applied to a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413 Dominique d'Humieres changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Dominique d'Humieres --- > I do not have any problems if you want to pick up where I left > off with this bug. I simply do not have much time for gfortran > anymore. The problem with the patch in comment #1 is that it uses mpfr_frexp which has been introduced in the mpfr release 3.1.0. AFAICT the GCC prerequisite is 2.4.2. Is there any plan to bump the prerequisite version?
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 --- Comment #11 from Allan McRae --- Created attachment 30345 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30345&action=edit log of gdb session Here is the log from my gdb session. Arch builds with no patches, just a could of small sed lines that should not affect this. See our build script (plain bash): https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/gcc Since it is also in Fedora rawhide, hopefully someone there can confirm.
[Bug c++/57684] [c++11] Lambda is not convertible to std::function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57684 --- Comment #1 from Jonathan Wakely --- I think the problem is that unordered_map requires its template arguments to be complete at the time of instantiation, otherwise it's undefined behaviour. When the static member is instantiated the type Derived is not complete, because base is instantiated before the body of derived. So although it would be nice if this worked, I think it technically relies on undefined behaviour.
[Bug c++/57684] [c++11] Lambda is not convertible to std::function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57684 --- Comment #2 from Francesco Biscani --- (In reply to Jonathan Wakely from comment #1) > I think the problem is that unordered_map requires its template arguments to > be complete at the time of instantiation, otherwise it's undefined behaviour. > > When the static member is instantiated the type Derived is not complete, > because base is instantiated before the body of derived. > > So although it would be nice if this worked, I think it technically relies > on undefined behaviour. Thanks for the quick reply! I understand this might be a bit OT here, but would wrapping the static member in an std::unique_ptr avoid UB?
[Bug c++/57208] Latest chromium compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 --- Comment #25 from Jan Hubicka --- Updated patch. Honza
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
Chung-Ju Wu changed:
What|Removed |Added
CC||jasonwucj at gmail dot com
--- Comment #19 from Chung-Ju Wu ---
(In reply to David Binderman from comment #17)
> (In reply to Daniel Marjamäki from comment #7)
> > In my experience this type of check is really noisy if there is a warning
> > for every fall through.
> >
> > I recommend that the warning is written only if the fall through cause
> > redundant or bad behaviour. such as:
> >
> > switch (foo) {
> > case 1: x = y; // <- redundant assignment
> > case 2: x = z;
> > };
>
> I'd be happy with gcc warning for this kind of problem.
>
> This specific case should be easier to catch than the
> general case.
I believe such redundant assignment will be optimized out.
$ gcc --version
gcc (20130621) 4.9.0 20130621 (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.
$ gcc -O2 -S pr7652.c
[pr7652.c]
1
2 extern int a;
3 extern int b;
4 extern int c;
5
6 int
7 main(int argc, char **argv)
8 {
9 int x;
10
11 switch (argc)
12 {
13 case 1:
14 x = a;
15 case 7:
16 x = b;
17 break;
18 default:
19 x = c;
20 break;
21 }
22
23 return x;
24 }
[pr7652.s]
1 .file "pr7652.c"
2 .section.text.startup,"ax",@progbits
3 .p2align 4,,15
4 .globl main
5 .type main, @function
6 main:
7 .LFB0:
8 .cfi_startproc
9 movl4(%esp), %eax
10 cmpl$1, %eax
11 je .L3
12 cmpl$7, %eax
13 je .L3
14 movlc, %eax
15 ret
16 .L3:
17 movlb, %eax
18 ret
19 .cfi_endproc
20 .LFE0:
21 .size main, .-main
22 .ident "GCC: (20130621) 4.9.0 20130621 (experimental)"
23 .section.note.GNU-stack,"",@progbits
Apparently it is dead code. IMHO, it may not be a good idea to
have compiler issue a warning everytime when compiler identifies
dead code statements.
[Bug c++/57684] [c++11] Lambda is not convertible to std::function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57684 --- Comment #3 from Jonathan Wakely --- Yes, because std::unique_ptr has a special exception that says it can be instantiated with incomplete types, so that should work OK (like your case where the static member is a raw pointer, which prevents unordered_map being instantiated when base<> is instantiated. I hope for GCC 4.9 we can make unordered_map support incomplete types again, so the original code would work, but it doesn't support them currently, which is allowed by the standard.
[Bug fortran/52413] Incorrect behavior of FRACTION when applied to a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413
--- Comment #6 from Francois-Xavier Coudert ---
The current patch is also lacking handling of the sign if signed zero is used.
This should do the trick:
if (mpfr_sgn (x->value.real) == 0)
{
- mpfr_set_ui (result->value.real, 0, GFC_RND_MODE);
+ mpfr_set (result->value.real, x->value.real, GFC_RND_MODE);
return result;
}
Using mpfr_frexp() is a good idea, and probably a gain in the long term (easier
maintenance), so we may wrap it inside version checks. Tentative patch:
Index: simplify.c
===
--- simplify.c(revision 200350)
+++ simplify.c(working copy)
@@ -2342,16 +2342,25 @@ gfc_expr *
gfc_simplify_fraction (gfc_expr *x)
{
gfc_expr *result;
+
+#if MPFR_VERSION < MPFR_VERSION_NUM(3,1,0)
mpfr_t absv, exp, pow2;
+#else
+ mpfr_exp_t e;
+#endif
if (x->expr_type != EXPR_CONSTANT)
return NULL;
result = gfc_get_constant_expr (BT_REAL, x->ts.kind, &x->where);
+#if MPFR_VERSION < MPFR_VERSION_NUM(3,1,0)
+
+ /* MPFR versions before 3.1.0 do not include mpfr_frexp. */
+
if (mpfr_sgn (x->value.real) == 0)
{
- mpfr_set_ui (result->value.real, 0, GFC_RND_MODE);
+ mpfr_set (result->value.real, x->value.real, GFC_RND_MODE);
return result;
}
@@ -2369,9 +2378,17 @@ gfc_simplify_fraction (gfc_expr *x)
mpfr_ui_pow (pow2, 2, exp, GFC_RND_MODE);
mpfr_div (result->value.real, absv, pow2, GFC_RND_MODE);
+ mpfr_copysign (result->value.real, result->value.real,
+ x->value.real, GFC_RND_MODE);
mpfr_clears (exp, absv, pow2, NULL);
+#else
+
+ mpfr_frexp (&e, result->value.real, x->value.real, GFC_RND_MODE);
+
+#endif
+
return range_check (result, "FRACTION");
}
However, I don't have a machine set up for bootstrapping (and regtesting) this
change. I just happened to pass by here :)
[Bug fortran/52413] Incorrect behavior of FRACTION when applied to a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413 --- Comment #7 from Francois-Xavier Coudert --- I forgot in the last comment to say: handling of sign for non-zero cases, in old MPFR versions, is done by this line which was missing in the existing code: + mpfr_copysign (result->value.real, result->value.real, + x->value.real, GFC_RND_MODE);
[Bug c++/57684] [c++11] Lambda is not convertible to std::function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57684 --- Comment #4 from Francesco Biscani --- (In reply to Jonathan Wakely from comment #3) > Yes, because std::unique_ptr has a special exception that says it can be > instantiated with incomplete types, so that should work OK (like your case > where the static member is a raw pointer, which prevents unordered_map being > instantiated when base<> is instantiated. > > I hope for GCC 4.9 we can make unordered_map support incomplete types again, > so the original code would work, but it doesn't support them currently, > which is allowed by the standard. Thanks for the explanation, gonna wrap my code in unique_ptr then. As a side note, this seems to work for std::map, are the requirements different regarding the completeness of types?
[Bug fortran/50550] does not recognize pointer variable at initialization (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50550 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org --- Comment #3 from janus at gcc dot gnu.org --- Here is a simple patch to accept the code in comment 0: Index: gcc/fortran/decl.c === --- gcc/fortran/decl.c(revision 200258) +++ gcc/fortran/decl.c(working copy) @@ -1197,6 +1197,9 @@ build_sym (const char *name, gfc_charlen *cl, bool sym->attr.implied_index = 0; + /* Update current_attr with merged symbol attributes. */ + current_attr = sym->attr; + if (sym->ts.type == BT_CLASS) return gfc_build_class_symbol (&sym->ts, &sym->attr, &sym->as, false); For cases like the one in comment 1, more work is required (which probably involves moving the corresponding check to resolution stage). Provided it is valid at all.
[Bug c++/57684] [c++11] Lambda is not convertible to std::function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57684 --- Comment #5 from Jonathan Wakely --- The standard says it is undefined to instantiate any std template with incomplete types (with exceptions for shared_ptr and unique_ptr and maybe a few others). As an extension libstdc++ allows all containers to be instantiated with incomplete types, except the unordered_xxx ones.
[Bug fortran/52413] Incorrect behavior of FRACTION when applied to a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413
--- Comment #8 from Dominique d'Humieres ---
Before going to the machinery in comment #6, the following patch (i.e., without
any mpfr_copysign)
--- ../_clean/gcc/fortran/simplify.c2013-06-08 21:50:33.0 +0200
+++ gcc/fortran/simplify.c2013-06-23 15:02:54.0 +0200
@@ -2351,7 +2351,7 @@ gfc_simplify_fraction (gfc_expr *x)
if (mpfr_sgn (x->value.real) == 0)
{
- mpfr_set_ui (result->value.real, 0, GFC_RND_MODE);
+ mpfr_set (result->value.real, x->value.real, GFC_RND_MODE);
return result;
}
@@ -2368,7 +2368,7 @@ gfc_simplify_fraction (gfc_expr *x)
mpfr_ui_pow (pow2, 2, exp, GFC_RND_MODE);
- mpfr_div (result->value.real, absv, pow2, GFC_RND_MODE);
+ mpfr_div (result->value.real, x->value.real, pow2, GFC_RND_MODE);
mpfr_clears (exp, absv, pow2, NULL);
passes my tests.
[Bug libquadmath/54012] printf crash with -lgfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54012 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-23 Component|libfortran |libquadmath Ever confirmed|0 |1 --- Comment #12 from Dominique d'Humieres --- Per comment #11, this is a libquadmath issue. Note that it works for me (without any valgrind error) from gcc version 4.6.4 up to trunk under 86_64-apple-darwin10 (without any valgrind error).
[Bug c++/57682] Uniform initialization syntax rejected in function-try-block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57682 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #3 from Paolo Carlini --- Easy to fix.
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 --- Comment #12 from Manuel López-Ibáñez --- (In reply to Allan McRae from comment #11) > Created attachment 30345 [details] > log of gdb session > > Here is the log from my gdb session. > > Arch builds with no patches, just a could of small sed lines that should not > affect this. See our build script (plain bash): > https://projects.archlinux.org/svntogit/packages.git/tree/trunk/ > PKGBUILD?h=packages/gcc Does it do a full bootstrap? My gdb session looks more optimized than yours. Perhaps it is a bug in the host compiler? My version also does not ever execute this: Breakpoint 1, linemap_add (set=0x77ff9000, reason=LC_ENTER, sysp=2, to_file=0x140e270 "/usr/include/stdc-predef.h", to_line=1) at /build/gcc-git/src/gcc/libcpp/line-map.c:291 In fact, I don't have this file. manuel@gcc10:~$ cat /etc/debian_version 6.0.6 so the presence of the file may make a difference (unfortunately, I don't have root access to gcc10 to fake the file and test).
[Bug c/57653] filename information discarded when using -imacros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653 --- Comment #13 from Allan McRae --- The Arch gcc does the full bootstrap. The debug build I am using was compiled with DEBUG_CFLAGS="-g -fvar-tracking-assignments". The file "/usr/include/stdc-predef.h" is from glibc (v2.17 on Arch) and is specifically mentioned as being preincluded in http://gcc.gnu.org/gcc-4.8/porting_to.html. In fact, using -ffreestanding "solves" the issue.
[Bug fortran/46299] Diagnose specification expressions involving host-associated vars with deferred bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46299 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-23 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Still present at revision 200321.
[Bug fortran/46271] OpenMP default(none) and procedure pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46271 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-23 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Still present at revision 200321.
[Bug fortran/52413] Incorrect behavior of FRACTION when applied to a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413 --- Comment #9 from Francois-Xavier Coudert --- > Before going to the machinery in comment #6, the following patch (i.e., > without any mpfr_copysign) Yep, you're right, no need for mpfr_copysign. Your patch looks good, if we don't want to introduce mpfr_frexp.
[Bug fortran/46485] gfortran.dg/allocatable_scalar_5.f90 fails on s390-ibm-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46485 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-23 CC||doko at debian dot org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- I don't see this failure for 4.6.4 (Debian 4.6.4-4) testsuite on s390-ibm-linux-gnu (http://gcc.gnu.org/ml/gcc-testresults/2013-06/msg02120.html). Shouldn't this PR be closed as FIXED?
[Bug tree-optimization/57685] New: GCC stuck in an infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57685
Bug ID: 57685
Summary: GCC stuck in an infinite loop
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: antoine.balestrat at gmail dot com
Hello !
Using GCC 4.9.0 as of 20130623 :
$ cat inf.c
unsigned f(void)
{
unsigned a;
int b, c, d, e;
for(c = 27; c < 40; c++)
b |= d |= b;
if(b)
a = e;
return a;
}
$ ulimit -t 60
$ xgcc -O3 inf.c
gcc: internal compiler error: CPU time limit exceeded (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug fortran/46982] SIZE(TRANSFER()) as specification expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46982 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-23 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Still present at revision 200321. Is the test in comment #0 valid or not?
[Bug fortran/41604] Reject result with assumed-length character in INTERFACE decl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41604 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-23 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- Still present at revision 200321.
[Bug target/39423] [4.7/4.8/4.9 Regression] [SH] performance regression: lost mov @(disp,Rn)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39423
--- Comment #36 from Oleg Endo ---
This is annoying:
int
foo (int tab[], int index)
{
return tab[index+1] + tab[index+2];
}
-O2 -m4 -mb:
add #1,r5
mov r4,r1
shll2 r5
add r5,r1
mov r5,r0
mov.l @(4,r1),r1
mov.l @(r0,r4),r2
add r1,r2
rts
mov r2,r0
should be:
shll2 r5
add r4,r5
mov.l @(4,r5),r0
mov.l @(8,r5),r1
rts
add r1,r0
Somehow this is a typical problem for combine based 'fixes' -- it works for a
single case, but falls apart when there are multiple uses of the same pattern.
[Bug tree-optimization/57685] GCC stuck in an infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57685 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson --- Also affects gcc-4.8-20130620, but not gcc-4.7-20130622, on x86_64-linux. A typical stack trace looks like: 0x008709d5 in register_new_assert_for (expr=0x7f24dc840c60, comp_code=EQ_EXPR, val=0x7f24dc855320, bb=, e=0x7f24dc975310, si=..., name=) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:4486 4486 if (loc->comp_code == comp_code Missing separate debuginfos, use: debuginfo-install glibc-2.15-59.fc17.x86_64 (gdb) bt #0 0x008709d5 in register_new_assert_for (expr=0x7f24dc840c60, comp_code=EQ_EXPR, val=0x7f24dc855320, bb=, e=0x7f24dc975310, si=..., name=) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:4486 #1 0x0087633b in register_edge_assert_for_1 (op=0x7f24dc840c60, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5217 #2 0x008764aa in register_edge_assert_for_1 (op=, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5250 #3 0x008764aa in register_edge_assert_for_1 (op=, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5250 #4 0x0087650b in register_edge_assert_for_1 (op=, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5252 #5 0x008764aa in register_edge_assert_for_1 (op=, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5250 #6 0x008764aa in register_edge_assert_for_1 (op=, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5250 #7 0x0087650b in register_edge_assert_for_1 (op=, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5252 #8 0x0087650b in register_edge_assert_for_1 (op=, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5252 #9 0x0087650b in register_edge_assert_for_1 (op=, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5252 #10 0x008764aa in register_edge_assert_for_1 (op=, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5250 #11 0x0087650b in register_edge_assert_for_1 (op=, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5252 #12 0x008764aa in register_edge_assert_for_1 (op=, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5250 #13 0x0087650b in register_edge_assert_for_1 (op=, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5252 #14 0x008764aa in register_edge_assert_for_1 (op=, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5250 #15 0x008764aa in register_edge_assert_for_1 (op=, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5250 #16 0x008764aa in register_edge_assert_for_1 (op=, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5250 #17 0x008764aa in register_edge_assert_for_1 (op=, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5250 #18 0x0087650b in register_edge_assert_for_1 (op=, code=code@entry=EQ_EXPR, e=e@entry=0x7f24dc975310, bsi=...) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5252 #19 0x00876886 in register_edge_assert_for (name=0x7f24dc840d38, e=e@entry=0x7f24dc975310, si=..., cond_code=, cond_op0=, cond_op1=0x7f24dc855320) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5347 #20 0x008772cb in find_conditional_asserts (last=0x7f24dc960aa0, bb=0x7f24dc9551a0) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5393 #21 find_assert_locations_1 (bb=bb@entry=0x7f24dc9551a0, live=0x26d6640) at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5607 #22 0x00882c19 in find_assert_locations () at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5747 #23 insert_range_assertions () at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:5935 #24 execute_vrp () at /tmp/gcc-4.8-20130620/gcc/tree-vrp.c:9287 #25 0x00695785 in execute_one_pass (pass=pass@entry=0x26e2900) at /tmp/gcc-4.8-20130620/gcc/passes.c:2330 #26 0x00695b45 in execute_pass_list (pass=0x26e2900) at /tmp/gcc-4.8-20130620/gcc/passes.c:2378 #27 0x00695b57 in execute_pass_list (pass=0x11ca2a0) at /tmp/gcc-4.8-201306
[Bug fortran/50550] does not recognize pointer variable at initialization (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50550 --- Comment #4 from janus at gcc dot gnu.org --- (In reply to janus from comment #3) > Here is a simple patch to accept the code in comment 0: ... which unfortunately introduces a large amount of ICEs in the testsuite, e.g. on bounds_check_7.f90: bounds_check_7.f90:5:0: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1265 subroutine foo(a) ^ 0x5d3a03 gfc_get_symbol_decl(gfc_symbol*) /home/janus/gcc49/trunk/gcc/fortran/trans-decl.c:1265 0x5d441f generate_local_decl /home/janus/gcc49/trunk/gcc/fortran/trans-decl.c:4726 0x5a2d43 do_traverse_symtree /home/janus/gcc49/trunk/gcc/fortran/symbol.c:3571 0x5d65ba generate_local_vars /home/janus/gcc49/trunk/gcc/fortran/trans-decl.c:4885 0x5d65ba gfc_generate_function_code(gfc_namespace*) /home/janus/gcc49/trunk/gcc/fortran/trans-decl.c:5460 That line is /* Dummy variables should already have been created. */ gcc_assert (sym->backend_decl); however, I don't directly see how the failure comes about.
[Bug fortran/52413] Incorrect behavior of FRACTION when applied to a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413
--- Comment #10 from Dominique d'Humieres ---
Here is the patch I plan to package and submit:
--- ../_clean/gcc/fortran/simplify.c2013-06-08 21:50:33.0 +0200
+++ gcc/fortran/simplify.c2013-06-23 17:19:55.0 +0200
@@ -2342,16 +2342,26 @@ gfc_expr *
gfc_simplify_fraction (gfc_expr *x)
{
gfc_expr *result;
+
+#if MPFR_VERSION < MPFR_VERSION_NUM(3,1,0)
mpfr_t absv, exp, pow2;
+#else
+ mpfr_exp_t e;
+#endif
if (x->expr_type != EXPR_CONSTANT)
return NULL;
result = gfc_get_constant_expr (BT_REAL, x->ts.kind, &x->where);
+#if MPFR_VERSION < MPFR_VERSION_NUM(3,1,0)
+
+ /* MPFR versions before 3.1.0 do not include mpfr_frexp.
+ TODO: remove the kludge when MPFR 3.1.0 or newer will be required */
+
if (mpfr_sgn (x->value.real) == 0)
{
- mpfr_set_ui (result->value.real, 0, GFC_RND_MODE);
+ mpfr_set (result->value.real, x->value.real, GFC_RND_MODE);
return result;
}
@@ -2368,10 +2378,16 @@ gfc_simplify_fraction (gfc_expr *x)
mpfr_ui_pow (pow2, 2, exp, GFC_RND_MODE);
- mpfr_div (result->value.real, absv, pow2, GFC_RND_MODE);
+ mpfr_div (result->value.real, x->value.real, pow2, GFC_RND_MODE);
mpfr_clears (exp, absv, pow2, NULL);
+#else
+
+ mpfr_frexp (&e, result->value.real, x->value.real, GFC_RND_MODE);
+
+#endif
+
return range_check (result, "FRACTION");
}
--- ../_clean/gcc/testsuite/gfortran.dg/fraction.f901970-01-01
01:00:00.0 +0100
+++ gcc/testsuite/gfortran.dg/fraction.f902013-06-23 17:25:09.0
+0200
@@ -0,0 +1,16 @@
+! { dg-do run }
+! Test for pr52413
+
+program test_frac
+
+ character(len=26) :: buf
+ real :: y
+ y=fraction (-2.0)
+ write (buf, *) y
+ if (buf(1:10) /= " -0.50") call abort ()
+ write (buf, *) fraction (-0.0)
+ if (buf(1:11) /= " -0.00") call abort ()
+ write (buf, *) fraction (-2.0_8)
+ if (buf(1:18) /= " -0.50") call abort ()
+
+end program test_frac
Any comment?
Since the PR is about wrong code, I think it qualifies for some backport with
the patch in comment #8. Should I do the tests or will the backport rejected?
[Bug fortran/52413] Incorrect behavior of FRACTION when applied to a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413 --- Comment #11 from Dominique d'Humieres --- Last question: should I include some tests for the other available kinds?
[Bug fortran/52413] Incorrect behavior of FRACTION when applied to a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413 --- Comment #12 from Francois-Xavier Coudert --- (In reply to Dominique d'Humieres from comment #10) > + y=fraction (-2.0) > + write (buf, *) y > + if (buf(1:10) /= " -0.50") call abort () Why involve I/O in your test, and not just test the value like that: if (fraction(-2.0) /= -0.5) call abort() and, slightly more complicated to handle negative zero, checking both value and sign: if (fraction(-0.0) /= 0.0) call abort if (sign(1.0, fraction(-0.0)) /= -1.0) call abort
[Bug testsuite/57686] New: FAIL: gcc.dg/torture/pr57584.c with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57686
Bug ID: 57686
Summary: FAIL: gcc.dg/torture/pr57584.c with -m32
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: dominiq at lps dot ens.fr
CC: hjl.tools at gmail dot com, rguenther at suse dot de
The tests gcc.dg/torture/pr57584.c fails in 32 bit mode:
FAIL: gcc.dg/torture/pr57584.c -O0 (test for excess errors)
FAIL: gcc.dg/torture/pr57584.c -O1 (test for excess errors)
FAIL: gcc.dg/torture/pr57584.c -O2 (test for excess errors)
FAIL: gcc.dg/torture/pr57584.c -O3 -fomit-frame-pointer (test for excess
errors)
FAIL: gcc.dg/torture/pr57584.c -O3 -fomit-frame-pointer -funroll-loops (test
for excess errors)
FAIL: gcc.dg/torture/pr57584.c -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions (test for excess errors)
FAIL: gcc.dg/torture/pr57584.c -O3 -g (test for excess errors)
FAIL: gcc.dg/torture/pr57584.c -Os (test for excess errors)
FAIL: gcc.dg/torture/pr57584.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none (test for excess errors)
(see http://gcc.gnu.org/ml/gcc-testresults/2013-06/msg02288.html ). The error
is
/opt/gcc/work/gcc/testsuite/gcc.dg/torture/pr57584.c: In function
'vm_debug_engine':
/opt/gcc/work/gcc/testsuite/gcc.dg/torture/pr57584.c:40:27: error: invalid
register name for 'jump_table'
register const void **jump_table asm ("r12");
[Bug testsuite/57687] New: 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 Bug ID: 57687 Summary: FAIL: c-c++-common/cilk-plus/AN/comma_exp.c on x86_64-apple-darwin10 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: bviyer at gcc dot gnu.org Host: x86_64-apple-darwin10 Target: x86_64-apple-darwin10 Build: x86_64-apple-darwin10 The test c-c++-common/cilk-plus/AN/comma_exp.c fails in g++ mode under x86_64-apple-darwin10: FAIL: c-c++-common/cilk-plus/AN/comma_exp.c -fcilkplus (test for excess errors) UNRESOLVED: c-c++-common/cilk-plus/AN/comma_exp.c -fcilkplus compilation failed to produce executable FAIL: c-c++-common/cilk-plus/AN/comma_exp.c -O0 -fcilkplus (test for excess errors) UNRESOLVED: c-c++-common/cilk-plus/AN/comma_exp.c -O0 -fcilkplus compilation failed to produce executable FAIL: c-c++-common/cilk-plus/AN/comma_exp.c -O1 -fcilkplus (test for excess errors) UNRESOLVED: c-c++-common/cilk-plus/AN/comma_exp.c -O1 -fcilkplus compilation failed to produce executable FAIL: c-c++-common/cilk-plus/AN/comma_exp.c -O2 -ftree-vectorize -fcilkplus (test for excess errors) UNRESOLVED: c-c++-common/cilk-plus/AN/comma_exp.c -O2 -ftree-vectorize -fcilkplus compilation failed to produce executable FAIL: c-c++-common/cilk-plus/AN/comma_exp.c -O3 -fcilkplus (test for excess errors) UNRESOLVED: c-c++-common/cilk-plus/AN/comma_exp.c -O3 -fcilkplus compilation failed to produce executable FAIL: c-c++-common/cilk-plus/AN/comma_exp.c -g -fcilkplus (test for excess errors) UNRESOLVED: c-c++-common/cilk-plus/AN/comma_exp.c -g -fcilkplus compilation failed to produce executable FAIL: c-c++-common/cilk-plus/AN/comma_exp.c -g -O0 -fcilkplus (test for excess errors) UNRESOLVED: c-c++-common/cilk-plus/AN/comma_exp.c -g -O0 -fcilkplus compilation failed to produce executable FAIL: c-c++-common/cilk-plus/AN/comma_exp.c -g -O1 -fcilkplus (test for excess errors) UNRESOLVED: c-c++-common/cilk-plus/AN/comma_exp.c -g -O1 -fcilkplus compilation failed to produce executable FAIL: c-c++-common/cilk-plus/AN/gather_scatter.c -g -O1 -fcilkplus execution test FAIL: c-c++-common/cilk-plus/AN/comma_exp.c -g -O2 -ftree-vectorize -fcilkplus (test for excess errors) UNRESOLVED: c-c++-common/cilk-plus/AN/comma_exp.c -g -O2 -ftree-vectorize -fcilkplus compilation failed to produce executable FAIL: c-c++-common/cilk-plus/AN/comma_exp.c -g -O3 -fcilkplus (test for excess errors) UNRESOLVED: c-c++-common/cilk-plus/AN/comma_exp.c -g -O3 -fcilkplus compilation failed to produce executable FAIL: c-c++-common/cilk-plus/AN/comma_exp.c -O3 -ftree-vectorize -fcilkplus -g (test for excess errors) UNRESOLVED: c-c++-common/cilk-plus/AN/comma_exp.c -O3 -ftree-vectorize -fcilkplus -g compilation failed to produce executable The error is FAIL: c-c++-common/cilk-plus/AN/comma_exp.c -fcilkplus (test for excess errors) Excess errors: cc1plus: error: '' has incomplete type /opt/gcc/work/gcc/testsuite/c-c++-common/cilk-plus/AN/comma_exp.c:55:1: error: invalid use of 'void' cc1plus: error: '' has incomplete type /opt/gcc/work/gcc/testsuite/c-c++-common/cilk-plus/AN/comma_exp.c:55:1: error: invalid use of 'void' UNRESOLVED: c-c++-common/cilk-plus/AN/comma_exp.c -fcilkplus compilation failed to produce executable
[Bug fortran/52413] Incorrect behavior of FRACTION when applied to a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413 --- Comment #13 from Dominique d'Humieres --- > Why involve I/O in your test, and not just test the value like that: > > if (fraction(-2.0) /= -0.5) call abort() > > and, slightly more complicated to handle negative zero, checking both > value and sign: > > if (fraction(-0.0) /= 0.0) call abort > if (sign(1.0, fraction(-0.0)) /= -1.0) call abort No good reason, I just did not think of a direct comparison. I'll do the change later. Thanks for the tips.
[Bug c++/57688] New: -O3 -march=native generates illegal opcode on AMD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57688 Bug ID: 57688 Summary: -O3 -march=native generates illegal opcode on AMD Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Created attachment 30347 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30347&action=edit C++ source code I just noticed that -march=native support broke from date 20130621 to 20130623 for AMD Phenom as follows [dcb@localhost foundBugs]$ ../results/bin/g++ -g -O3 -Wall bug113.cc [dcb@localhost foundBugs]$ ./a.out Time for caxpy1 = 0.16 seconds [5120 Mflops] [dcb@localhost foundBugs]$ ../results/bin/g++ -g -O3 -march=native -Wall bug113.cc [dcb@localhost foundBugs]$ ./a.out Illegal instruction (core dumped) [dcb@localhost foundBugs]$ Valgrind helps out with this vex amd64->IR: unhandled instruction bytes: 0x8F 0xEA 0xF8 0x10 0xD2 0x2 0x1E 0x0 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==23912== valgrind: Unrecognised instruction at address 0x4045e2. ==23912==at 0x4045E2: caxpy3(Vector&, Vector&, Complex) (bug113.cc:52) ==23912==by 0x4012C0: main (bug113.cc:258) ==23912== Your program just tried to execute an instruction that Valgrind ==23912== did not recognise. There are two possible reasons for this. ==23912== 1. Your program has a bug and erroneously jumped to a non-code ==23912==location. If you are running Memcheck and you just saw a ==23912==warning about a bad jump, it's probably your program's fault. ==23912== 2. The instruction is legitimate but Valgrind doesn't handle it, ==23912==i.e. it's Valgrind's fault. If you think this is the case or ==23912==you are not sure, please let us know and we'll try to fix it. ==23912== Either way, Valgrind will now raise a SIGILL signal which will ==23912== probably kill your program. ==23912== ==23912== Process terminating with default action of signal 4 (SIGILL) ==23912== Illegal opcode at address 0x4045E2 ==23912==at 0x4045E2: caxpy3(Vector&, Vector&, Complex) (bug113.cc:52) Also [dcb@localhost foundBugs]$ head /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 4 model name : AMD Phenom(tm) II X4 970 Processor stepping: 3 microcode : 0x1c8 cpu MHz : 3500.000 cache size : 512 KB physical id : 0
[Bug c++/57688] -O3 -march=native generates illegal opcode on AMD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57688 --- Comment #1 from Mikael Pettersson --- Run it in gdb, wait for the fault, and disassemble the code around the faulting PC. That valgrind report doesn't really say anything useful.
[Bug target/57688] -O3 -march=native generates illegal opcode on AMD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57688 Paolo Carlini changed: What|Removed |Added Component|c++ |target --- Comment #2 from Paolo Carlini --- Doesn't look like a C++ front-end issue.
[Bug target/56997] Incorrect write to packed field when strict-volatile-bitfields enabled on aarch32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- Comment #6 from Bernd Edlinger ---
(In reply to Sandra Loosemore from comment #5)
> Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00750.html
Hi Sandra,
I tried your patch, but I dont like the code that it generates:
printf("%x\n", (unsigned int)g.b);
g.b = 0xAAA;
is compiled to invalid code (in ARMv5)
ldr r4, .L2
ldr r1, [r4]
ldr r3, [r4, #4]
and r3, r3, #7
mov r3, r3, asl #25
orr r1, r3, r1, lsr #7
ldr r0, .L2+4
bl printf
ldr r2, [r4]
ldr r3, .L2+8
and r2, r2, #127
orr r3, r2, r3
str r3, [r4]
ldr r3, [r4, #4]
bic r3, r3, #7
orr r3, r3, #5
str r3, [r4, #4]
code is invalid because: the object "g" is only 5 bytes large,
but the first statement reads 2x4 bytes, and ignores the 3 extra bytes.
this can fault if g is close to a segment boundary.
The second statement reads the 3 bytes beyond g and writes them
unmodified back. That is problematic if a task switch occurs between the
read and store sequence, and the other task modifies something in the 3 bytes.
Previous versions of gcc produced single 5x1 byte read/write sequences for
that structure, as does apparently the x86 version.
Regards
Bernd.
[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 #1 from Paolo Carlini --- On x86_64-linux, c-c++-common/cilk-plus/AN/gather_scatter.c fails, not sure if it's a related issue or I should open a Bugzilla. See also gcc-testresults.
[Bug target/57688] -O3 -march=native generates illegal opcode on AMD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57688 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Also, for any bugreport with -march=native or -mtune=native you need to specify what options have been passed to cc1plus/cc1 (add -v), plus you haven't provided preprocessed source.
[Bug fortran/42945] Gcov -a fails on Fortan generated object file (infinite loop?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42945 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-23 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres --- Is the problem still there? I cannot reproduce it with trunk: 'gcov -abcfu mdl.f90' executes in milliseconds (I don't have lcov).
[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 #2 from Dominique d'Humieres --- > On x86_64-linux, c-c++-common/cilk-plus/AN/gather_scatter.c fails, > not sure if it's a related issue or I should open a Bugzilla. > See also gcc-testresults. AFAICT the failures for comma_exp.c are darwin specific (at least I don't see them on the Intel bots), while the gather_scatter.c seems wide spread. I was planning a different PR for them, but if you beat me, I won't cry!-).
[Bug target/57688] -O3 -march=native generates illegal opcode on AMD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57688 --- Comment #4 from David Binderman --- (In reply to Mikael Pettersson from comment #1) > Run it in gdb, wait for the fault, and disassemble the code around the > faulting PC. That valgrind report doesn't really say anything useful. 0x004045d4 <+948>:lea-0x5(%r9),%edx 0x004045d8 <+952>:lea0x140(%r10),%rsi 0x004045df <+959>:mov%rax,%rcx => 0x004045e2 <+962>:bextr $0x1e02,%rdx,%rdx 0x004045eb <+971>:xor%r8d,%r8d 0x004045ee <+974>:shl$0x6,%rdx 0x004045f2 <+978>:lea0x180(%r10,%rdx,1),%rdi
[Bug target/57688] -O3 -march=native generates illegal opcode on AMD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57688 --- Comment #5 from Andrew Pinski --- Can you provide the full output of "cat /proc/cpuinfo" and not just the head?
[Bug target/57688] -O3 -march=native generates illegal opcode on AMD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57688 --- Comment #6 from David Binderman --- Created attachment 30348 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30348&action=edit preprocessed C++ source code
[Bug tree-optimization/57685] GCC stuck in an infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57685 --- Comment #2 from Mikael Pettersson --- Started with the PR55079 fix in r193098. The test case uses the values of uninitialized auto variables, perhaps that's confusing the compiler.
[Bug target/57688] -O3 -march=native generates illegal opcode on AMD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57688 --- Comment #7 from David Binderman --- (In reply to Andrew Pinski from comment #5) > Can you provide the full output of "cat /proc/cpuinfo" and not just the head? processor: 0 vendor_id: AuthenticAMD cpu family: 16 model: 4 model name: AMD Phenom(tm) II X4 970 Processor stepping: 3 microcode: 0x1c8 cpu MHz: 3500.000 cache size: 512 KB physical id: 0 siblings: 4 core id: 0 cpu cores: 4 apicid: 0 initial apicid: 0 fpu: yes fpu_exception: yes cpuid level: 5 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monito r cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3d nowprefetch osvw ibs skinit wdt nodeid_msr hw_pstate npt lbrv svm_lock nrip_save bogomips: 7031.52 TLB size: 1024 4K pages clflush size: 64 cache_alignment: 64 address sizes: 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate
[Bug target/57688] -O3 -march=native generates illegal opcode on AMD Phenom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57688 --- Comment #8 from David Binderman --- (In reply to Jakub Jelinek from comment #3) > Also, for any bugreport with -march=native or -mtune=native you need to > specify what options have been passed to cc1plus/cc1 (add -v), plus you > haven't provided preprocessed source. /home/dcb/gcc/results/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1plus -quiet -v -D_GNU_SOURCE bug113.cc -march=amdfam10 -mmmx -m3dnow -msse -msse2 -msse3 -m no-ssse3 -msse4a -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt -mabm -m no-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx 2 -mno-sse4.2 -mno-sse4.1 -mlzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fs gsbase -mno-rdseed -mprfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt --param l1- cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=amd fam10 -quiet -dumpbase bug113.cc -auxbase bug113 -g -O3 -version -o /tmp/ccpBZ0u f.s
[Bug target/57688] -O3 -march=native generates illegal opcode on AMD Phenom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57688 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #9 from Mikael Pettersson --- Your toolchain generated an AMD XOP BEXTR insn, but your processor doesn't have the XOP ISA extensions, so it #UDs.
[Bug go/57689] New: [4.8 Regression] ICE (segfault) building libgo on ia64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57689 Bug ID: 57689 Summary: [4.8 Regression] ICE (segfault) building libgo on ia64-linux-gnu Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: doko at gcc dot gnu.org libgo fails to build on ia64-linux-gnu, with r200219, the last successful build was with r200018. A build from the trunk on 20130620 did succeed. /bin/mkdir -p .; files=`echo ../../../src/libgo/go/regexp/exec.go ../../../src/libgo/go/regexp/regexp.go bytes.gox io.gox regexp/syntax.gox strconv.gox strings.gox sync.gox unicode.gox unicode/utf8.gox | sed -e 's/[^ ]*\.gox//g'`; /bin/bash ./libtool --tag GO --mode=compile /«PKGBUILDDIR»/build/./gcc/gccgo -B/«PKGBUILDDIR»/build/./gcc/ -B/usr/ia64-linux-gnu/bin/ -B/usr/ia64-linux-gnu/lib/ -isystem /usr/ia64-linux-gnu/include -isystem /usr/ia64-linux-gnu/sys-include -isystem /«PKGBUILDDIR»/build/sys-include -O2 -g -I . -c -fgo-pkgpath=`echo regexp.lo | sed -e 's/.lo$//' -e 's/-go$//'` -o regexp.lo $files libtool: compile: /«PKGBUILDDIR»/build/./gcc/gccgo -B/«PKGBUILDDIR»/build/./gcc/ -B/usr/ia64-linux-gnu/bin/ -B/usr/ia64-linux-gnu/lib/ -isystem /usr/ia64-linux-gnu/include -isystem /usr/ia64-linux-gnu/sys-include -isystem /«PKGBUILDDIR»/build/sys-include -O2 -g -I . -c -fgo-pkgpath=regexp ../../../src/libgo/go/regexp/exec.go ../../../src/libgo/go/regexp/regexp.go -fPIC -o .libs/regexp.o ../../../src/libgo/go/regexp/regexp.go: In function 'regexp.$nested3': ../../../src/libgo/go/regexp/regexp.go:528:2: internal compiler error: Segmentation fault }) ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make[6]: *** [regexp.lo] Error 1
[Bug target/57688] [4.9 Regression] -O3 -march=native generates illegal opcode on AMD Phenom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57688 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 Summary|-O3 -march=native generates |[4.9 Regression] -O3 |illegal opcode on AMD |-march=native generates |Phenom |illegal opcode on AMD ||Phenom --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Sun Jun 23 19:06:00 2013 New Revision: 200352 URL: http://gcc.gnu.org/viewcvs?rev=200352&root=gcc&view=rev Log: PR target/57688 * common/config/i386/i386-common.c (ix86_handle_option): For OPT_mlzcnt add missing return true. Modified: trunk/gcc/ChangeLog trunk/gcc/common/config/i386/i386-common.c Fixed. BTW, with explicit -mtbm we still generate: bextr$7682, %rdx, %rdx while without it we generate much more compact: shrl $2, %rdx Will create a PR for that.
[Bug target/57690] New: bextr sometimes used instead of shr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57690
Bug ID: 57690
Summary: bextr sometimes used instead of shr
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
unsigned int bar (void);
unsigned long foo (unsigned int x) { return bar () >> 2; }
With -O2 -mtbm we get:
0:48 83 ec 08 sub$0x8,%rsp
4:e8 00 00 00 00 callq 9
5: R_X86_64_PC32bar-0x4
9:48 83 c4 08 add$0x8,%rsp
d:8f ea f8 10 c0 02 1e bextr $0x1e02,%rax,%rax
14:00 00
16:c3 retq
while without it:
0:48 83 ec 08 sub$0x8,%rsp
4:e8 00 00 00 00 callq 9
5: R_X86_64_PC32bar-0x4
9:48 83 c4 08 add$0x8,%rsp
d:c1 e8 02 shr$0x2,%eax
10:c3 retq
which is much shorter. On the other side, bextr with immediate gives more
freedom to the register allocator, because it is a non-destructive source
instruction. So, perhaps we want a peephole2 which will transform some forms
of the immediate TARGET_TBM tbm_bextr* (those where upper bits of a SImode or
DImode value are extracted and where destination is the same as source) into
shrl.
For -Os maybe it would be even shorter to emit movl + shrl.
[Bug libstdc++/57691] New: freestanding libstdc++ has compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691
Bug ID: 57691
Summary: freestanding libstdc++ has compile error
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Created attachment 30349
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30349&action=edit
Proposed fix for this problem
Hello,
I want to compile the gcc-4.8.1 in a freestanding environment (eCos)
but I encountered a compile error in libstdc++-v3/libsupc++/atexit_thread.cc:
../../../../gcc-4.8.1/libstdc++-v3/libsupc++/atexit_thread.cc: In function
'void {anonymous}::key_init()':
../../../../gcc-4.8.1/libstdc++-v3/libsupc++/atexit_thread.cc:87:21: error: no
matches converting function 'run' to type 'void (*)(...)
std::atexit (run);
^
../../../../gcc-4.8.1/libstdc++-v3/libsupc++/atexit_thread.cc:66:8: note:
candidates are: void {anonymous}::run()
void run ()
^
../../../../gcc-4.8.1/libstdc++-v3/libsupc++/atexit_thread.cc:58:8: note:
void {anonymous}::run(void*)
void run (void *p)
^
../../../../gcc-4.8.1/libstdc++-v3/libsupc++/atexit_thread.cc: In function 'int
__cxxabiv1::__cxa_thread_atexit(void (*)(void*), void*, void*)':
../../../../gcc-4.8.1/libstdc++-v3/libsupc++/atexit_thread.cc:109:20: error: no
matches converting function 'run' to type 'void (*)(...)'
std::atexit (run);
^
../../../../gcc-4.8.1/libstdc++-v3/libsupc++/atexit_thread.cc:66:8: note:
candidates are: void {anonymous}::run()
void run ()
^
../../../../gcc-4.8.1/libstdc++-v3/libsupc++/atexit_thread.cc:58:8: note:
void {anonymous}::run(void*)
void run (void *p)
^
The used config parameters are:
../gcc-4.8.1/configure --target=arm-eabi --prefix=/home/ed/gnu/arm-eabi
--with-newlib --enable-languages=c,c++ --disable-hosted-libstdcxx
--disable-__cxa_atexit
The compiler is simply right to complain about the ambiguity here:
The problem is the function atexit() that is declared in cstdlib
to take a parameter 'void (*)()' which means any parameter or nothing can
match.
now there are two global functions named run in this scope
one declared 'void run()' and one declared void run(void*)'.
The first one would be the correct choice.
To fix that I had to changemthe declaration of atexit() in cstdlib:
atexit(void (*)()) => atexit(void (*)(void))
which is consistent with glibc's atexit() declaraion in stdlib.h
furthermore the declaration of at_quick_exit() has the same bug.
[Bug c++/51213] [C++11][DR 1170] Access control checking has to be done under SFINAE conditions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51213
Shane changed:
What|Removed |Added
CC||w.shane.grant at gmail dot com
--- Comment #16 from Shane ---
I think some variant of this bug may still exist (using g++ (Ubuntu
4.8.1-2ubuntu1~13.04) 4.8.1). The following code will fail to compile under
g++ but will correctly compile under a recent version of clang++ (3.3).
template
T && declval();
template
constexpr auto hasSize(int) -> decltype(declval().size(), bool())
{ return true; }
template
constexpr bool hasSize(...)
{ return false; }
struct A
{
int size();
};
struct B : private A
{
};
static_assert(hasSize(0), "A");
static_assert(!hasSize(0), "B");
int main() {}
The error produced is:
test.cpp: In substitution of ‘template constexpr decltype
((declval().size(), bool())) hasSize(int) [with T = B]’:
test.cpp:22:28: required from here
test.cpp:5:61: error: ‘A’ is not an accessible base of ‘B’
constexpr auto hasSize(int) -> decltype(declval().size(), bool())
^
test.cpp: In substitution of ‘template constexpr decltype
((declval().size(), bool())) hasSize(int) [with T = B]’:
test.cpp:22:28: required from here
test.cpp:5:61: error: ‘A’ is not an accessible base of ‘B’
[Bug fortran/57639] [OOP] ICE with polymorphism (and illegal code)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57639 --- Comment #4 from janus at gcc dot gnu.org --- (In reply to janus from comment #3) > The following patch fixes both variants: ... and regtests cleanly.
[Bug c/57692] New: FAIL: c-c++-common/cilk-plus/AN/gather_scatter.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57692 Bug ID: 57692 Summary: FAIL: c-c++-common/cilk-plus/AN/gather_scatter.c Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: bviyer at gcc dot gnu.org The test c-c++-common/cilk-plus/AN/gather_scatter.c fails for both C and C++ (see http://gcc.gnu.org/ml/gcc-testresults/2013-06/msg02301.html ).
[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 Dominique d'Humieres changed: What|Removed |Added Version|unknown |4.9.0 --- Comment #3 from Dominique d'Humieres --- Possibly related to pr57692.
[Bug target/56997] Incorrect write to packed field when strict-volatile-bitfields enabled on aarch32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997
--- Comment #7 from Bernd Edlinger ---
aehmm sorry, the object "g" from above code is actually from PR#48784
#pragma pack(1)
volatile struct S0 {
signed a : 7;
unsigned b : 28;
} g = {0,-1};
=> sizeof(g) = 5
but the code from this example has pretty much the same problems:
typedef struct s{
unsigned char Prefix;
test_type Type;
}__attribute((__packed__)) ss;
=> sizeof(ss) = 5
foo:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldr r3, .L2
ldr r2, [r3]
and r2, r2, #255
orr r2, r2, r0, asl #8
str r2, [r3]
ldr r2, [r3, #4]
bic r2, r2, #255
orr r0, r2, r0, lsr #24
str r0, [r3, #4]
bx lr
accesses 8 bytes
[Bug c++/51213] [C++11][DR 1170] Access control checking has to be done under SFINAE conditions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51213 --- Comment #17 from Paolo Carlini --- But this example works in mainline (would be 4.9.0) and I don't think it's a regression.
[Bug fortran/46982] SIZE(TRANSFER()) as specification expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46982 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #3 from Harald Anlauf --- (In reply to Dominique d'Humieres from comment #2) > Still present at revision 200321. Is the test in comment #0 valid or not? Probably a case where the standard is not intuitive: size(transfer(something_type(),(/0/))) is a constant expression, but size(transfer(something,(/0/))) apparently is not, simply because "something" is not constant. IMO it also appears not to qualify as a specification expression. Replacing type(something_type),save :: something by type(something_type),parameter :: something = something_type() would change something into a constant and make the code compile. So I think that the code in comment #0 is not legal.
[Bug fortran/46982] SIZE(TRANSFER()) as specification expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46982 --- Comment #4 from Dominique d'Humieres --- > ... So I think that the code in comment #0 is not legal. Then, should not this PR closed as INVALID?
[Bug target/56997] Incorrect write to packed field when strict-volatile-bitfields enabled on aarch32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997 --- Comment #8 from Sandra Loosemore --- Thanks for giving it a try. Do you think that in a case such as this where a single access of the appropriate size cannot be generated due to the struct having unaligned fields we should generate the same code as with -fno-strict-volatile-bitfields, or something else? I agree the behavior of my current patch is problematical here, but we need to decide what this case is supposed to do before I can figure out how to fix the code.
[Bug testsuite/57686] FAIL: gcc.dg/torture/pr57584.c with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57686 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-24 Version|unknown |4.9.0 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- .
[Bug fortran/40958] module files too large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958 --- Comment #14 from Joost VandeVondele --- (In reply to Janne Blomqvist from comment #13) I believe a lot of progress has been made indeed. > However, the fundamental(?) issue of module sizes growing exponentially with > deep module hierarchies still remains. The solution to that is to not > include transitive dependencies, which in turn would require a module cache > for good performance. Whether that is worth doing, and who is willing and > able to do it, is unclear. note that there could also be disadvantages for that solution. For example, dependencies for a given .F would be more difficult to find (i.e. not just the USE statements). I'm not sure what implications that would have e.g. for 'smart' recompilation (i.e. based on time stamps of .mod). The module cache would also not work very well for the (common, I guess) case of having a single module per file, and all USE statements on top. It might thus be that the current state is the sweet spot.
[Bug fortran/52606] Confusing diagnostics for long identifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52606 Dominique d'Humieres changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #8 from Dominique d'Humieres --- Was marked as ASSIGNED, but actually "Not yet assigned to anyone". Set to NEW.
[Bug fortran/47267] array constructor causing long compile times
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47267 Dominique d'Humieres changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #6 from Dominique d'Humieres --- Was marked as ASSIGNED, but actually "Not yet assigned to anyone". Set to NEW.
