https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64875
Bug ID: 64875
Summary: -Winline does not report C++ methods
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64212
--- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #2)
Reduced testcase:
inline void
foo (void)
{
}
__attribute__ ((__dllimport__))
void foo (void);
void
bar (void)
{
foo ();
}
On Fri, 30 Jan 2015, Mikhail Maltsev wrote:
On Fri, 30 Jan 2015 00:15:02 +
Joseph Myers jos...@codesourcery.com wrote:
+#if 0
+ /* Check needs to be implemented. */
+ fuic (-1. + 0.i);
+ vuic = -1. + 0.i;
+#endif
The #if 0 cases should have a bug filed in Bugzilla
On Fri, Jan 30, 2015 at 08:27:06AM -0800, Mike Stump wrote:
+static bool
+c_parse_pragma_ivdep (c_parser *parser)
+{
+ c_parser_consume_pragma (parser);
+ c_parser_skip_to_pragma_eol (parser);
+ return true;
+}
+
+static unsigned short
+c_parser_pragma_unroll (c_parser *parser)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
--- Comment #11 from Jan Hubicka hubicka at gcc dot gnu.org ---
Yep, I think the problem is that each of DSOs will have its own set of infos
that will point to its own gcov_merge_add that calls its own gcov_io routines.
Now the winning gcov will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
--- Comment #13 from Nathan Sidwell nathan at acm dot org ---
No. Each dso's gcov machinery is individually invoked. There should be no
cross-dso accessing of data (beyond the global chain of dso)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #6 from Tom Tromey tromey at gcc dot gnu.org ---
Also, -Wconditionally-supported triggers other warning as well.
It would be more convenient if different warnings were individually
controllable; and then something like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64878
Bug ID: 64878
Summary: [5 Regression] Miscompilation of nntpgrab
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64877
Bug ID: 64877
Summary: strange warning message from -Waddress
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20710
Tom Tromey tromey at gcc dot gnu.org changed:
What|Removed |Added
CC||tromey at gcc dot
On Jan 30, 2015, at 4:22 AM, Jonny Grant j...@jguk.org wrote:
Hello
When I checked out from the trunk I saw that various files had .C
capital extension. Its not a big issue.. but I wondered if they should
be .c like regular source files?
No because they are c++ code so capital C is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
--- Comment #14 from Nathan Sidwell nathan at acm dot org ---
Jan, I'm fairly sure that even though your fix makes things work, it is wrong.
You're at the very least exposing an internal API across the DSO boundary,
which should not be exposed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64878
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
On Thu, 29 Jan 2015, Mike Stump wrote:
@@ -5587,6 +5600,12 @@ c_parser_for_statement (c_parser *parser
%GCC ivdep% pragma);
cond = error_mark_node;
}
+ else if (unroll)
+ {
+ c_parser_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
--- Comment #12 from Jan Hubicka hubicka at gcc dot gnu.org ---
BTW the following fix the issue for me
Index: gcov-io.c
===
--- gcov-io.c (revision 220230)
+++ gcov-io.c (working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64878
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P1
Avoid possible warning on darwin during compiler build.
Should hopefully close PR 64349, committed on trunk
2015-01-30 Tristan Gingold ging...@adacore.com
PR ada/64349
* env.c: Move vxworks and darwin includes out of #ifdef IN_RTS.
Index: env.c
On Jan 30, 2015, at 7:49 AM, Joseph Myers jos...@codesourcery.com wrote:
Use error_at, and %u directly in the format.
Done.
Index: ada/gcc-interface/trans.c
===
--- ada/gcc-interface/trans.c (revision 220084)
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64876
Bug ID: 64876
Summary: Regressions in gcc-testresults for powerpc64 gccgo in
5.0 due to change for static chain for closures
(219776)
Product: gcc
Version: 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org ---
(In reply to Tom Tromey from comment #5)
(In reply to Jason Merrill from comment #3)
Passing a non-POD to a varargs function is conditionally-supported, with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64349
--- Comment #12 from Arnaud Charlet charlet at gcc dot gnu.org ---
Author: charlet
Date: Fri Jan 30 15:13:15 2015
New Revision: 220285
URL: https://gcc.gnu.org/viewcvs?rev=220285root=gccview=rev
Log:
2015-01-30 Tristan Gingold
This patch fixes a rather obscure bug in case there is a user-defined +
operator returning Boolean, passed to two contexts where the expected type is
Boolean, and the expected type is the result of the PREdefined operator.
This is ambiguous, and therefore illegal.
gnatmake -q -f cutdown1-main.adb
Hi Tristan,
On 30 Jan 2015, at 15:13, Arnaud Charlet wrote:
Avoid possible warning on darwin during compiler build.
it's not just a warning it's a documented incorrect usage which causes a link
error (and thus bootstrap fail) on systems that are not using the catch-all
-Wl, -undefined,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #5 from Tom Tromey tromey at gcc dot gnu.org ---
(In reply to Jason Merrill from comment #3)
Passing a non-POD to a varargs function is conditionally-supported, with
implementation-defined semantics. In GCC 5 it's supported and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
Nathan Sidwell nathan at acm dot org changed:
What|Removed |Added
CC||nathan at acm dot
The warning for use of Import in a Pure unit is refined so that it is
omitted if an explicit Pure_Function aspect is given, as shown by
the following test, compiled with -gnatl
1. package PureImportF is
2. pragma Pure (PureImportF);
3.function F (A : integer) return integer;
On Jan 29, 2015, at 7:16 PM, Andrew Pinski pins...@gmail.com wrote:
On Thu, Jan 29, 2015 at 6:58 PM, Mike Stump mikest...@comcast.net wrote:
On Jan 29, 2015, at 4:15 PM, Joseph Myers jos...@codesourcery.com wrote:
The patch is OK for GCC 6
We will be releasing 5.x compilers for the next
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356
--- Comment #14 from fiesh at zefix dot tv ---
Bounty: EUR 150
I'd like to try something new and place a bounty on this issue. In order to
collect it, you have to provide a patch that is accepted into 4.9 and 5. You
also need to be able to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org ---
See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2342.htm . It does
look like gcc is implementing the correct new pod rules and clang is not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64349
Arnaud Charlet charlet at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64212
--- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org ---
A side-note: Of course the dllimport attribute is part of the prototype. So
for C case it would be consistent to have the dllimport-attribute also
specified for the inline, which gets
This is the followup patch. This adds more information to the package
when any imported packages have a pkgpath symbol that is not the
obvious transformation of the pkgpath. This is enough to determine
the right symbol name to use in all cases. Bootstrapped and ran Go
testsuite on
On Fri, Jan 30, 2015 at 12:52 AM, Joseph Myers jos...@codesourcery.com wrote:
Ian: this patch does *not* change go/gofrontend/go.cc; you'll need to
update that (such an update is of course best done before this patch
goes in; since the overload currently exists, updating it does not
depend on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64873
--- Comment #2 from David Malcolm dmalcolm at gcc dot gnu.org ---
I think this is misconfigurfation at my end; sorry.
I'm on power7 hw, emulating via qemu, and I did *not*
configure with the options suggested by Jakub in comment #1;
so I think
pins...@gmail.com writes:
No because they are c++ code so capital C is correct.
However, we should avoid relying on case-sensitive file systems
(Windows) and use .cc or .cxx for C++ files (+ is not a valid file
name character on Windows, so we can't use .c++).
On 01/30/2015 12:40 PM, Richard Biener wrote:
On January 30, 2015 9:18:57 PM CET, Richard Henderson r...@redhat.com wrote:
On 01/30/2015 12:12 PM, Mike Stump wrote:
On Jan 30, 2015, at 9:52 AM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Jan 30, 2015 at 09:45:26AM -0800, Mike Stump wrote:
I
Hi,
This patch fixes two more cases where alias chain should be followed to emit
correct assembler name for instrumented functions. Bootstrapped and tested on
x86_64-unknown-linux-gnu. OK for trunk?
Thanks,
Ilya
--
gcc/
2015-01-30 Ilya Enkovich ilya.enkov...@intel.com
* varasm.c
The patch in the attachment solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64688
The patch was bootstrapped and tested on x86-64 and ppc64.
Committed as rev.220297.
2015-01-30 Vladimir Makarov vmaka...@redhat.com
PR target/64688
* lra-constraints.c
Similar to the issue with fatal_error that I fixed in
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02690.html, the
overloads of gfc_warning and gfc_warning_now (with and without a first
argument for an option number) also break gcc.pot regeneration because
xgettext expects the translated string
Am 30.01.2015 um 22:39 schrieb DJ Delorie d...@redhat.com:
pins...@gmail.com writes:
No because they are c++ code so capital C is correct.
However, we should avoid relying on case-sensitive file systems
(Windows) and use .cc or .cxx for C++ files (+ is not a valid file
name character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
On 01/30/2015 09:47 AM, Jakub Jelinek wrote:
+hash_maptree, tree *deep_ter_debug_map;
Any reason this data can't be static?
Otherwise, ok.
r~
On 01/30/2015 04:52 AM, Szabolcs Nagy wrote:
When running natively on AArch64 the preprocessor did not use the
AdvSIMD optimized search_line_fast function, because it was ifdefed
around by __ARM_NEON__ instead of __ARM_NEON.
Yes, sorry I didn't follow up on that from September:
On 01/30/15 03:24, Jakub Jelinek wrote:
On Fri, Jan 30, 2015 at 11:23:38AM +0100, Uros Bizjak wrote:
On Fri, Jan 30, 2015 at 11:13 AM, Jakub Jelinek ja...@redhat.com wrote:
/* Each function should compile down to a byte move from
the input register into x, possibly at an offset within
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63472
--- Comment #6 from torvald at gcc dot gnu.org ---
(In reply to ak from comment #4)
copy_bbs:
(illegal code due to goto into transaction?)
g_56[];
fn1() {
int *p_79;
if (g_56[7])
__transaction_atomic {
lbl_196:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63472
--- Comment #7 from Benjamin Braun bjmnbraun at gmail dot com ---
A workaround for the code at the top of this thread is to wrap the transaction
in the loop with a function and instead call that function from the loop.
This workaround also
On Fri, 30 Jan 2015, David Malcolm wrote:
gcc/ChangeLog:
PR jit/64810
* Makefile.in (GCC_OBJS): Add gcc-main.o.
* gcc-main.c: New file, containing main taken from gcc.c.
* gcc.c (do_self_spec): Free decoded_options.
(class driver): Move declaration to gcc.h.
On 01/30/2015 03:36 PM, Aldy Hernandez wrote:
/* It is possible to have both DECL_ABSTRACT_P and DECLARATION be true if we
started to generate the abstract instance of an inline, decided to output
its containing class, and proceeded to emit the declaration of the inline
from the
On 30 January 2015 at 23:06, Ville Voutilainen
ville.voutilai...@gmail.com wrote:
Let's drop libstdc++, this discussion is about a test that doesn't
really concern them.
On 30 January 2015 at 22:51, Jason Merrill ja...@redhat.com wrote:
The patch changes all the static_assert strings to ,
The related warning (cross compile tile with --disable-threads):
../../../../gcc-tile-new/libgcc/libgcov-interface.c: In function
'__gcov_fork':
../../../../gcc-tile-new/libgcc/libgcov-interface.c:182:53: warning: suggest
braces around empty body in an 'if' statement [-Wempty-body]
On Sat, Jan 31, 2015 at 06:37:30AM +0800, Chen Gang S wrote:
The related warning (cross compile tile with --disable-threads):
../../../../gcc-tile-new/libgcc/libgcov-interface.c: In function
'__gcov_fork':
../../../../gcc-tile-new/libgcc/libgcov-interface.c:182:53: warning:
suggest
On January 30, 2015 5:36:16 PM GMT+01:00, Marek Polacek pola...@redhat.com
wrote:
On Fri, Jan 30, 2015 at 08:27:06AM -0800, Mike Stump wrote:
+static bool
+c_parse_pragma_ivdep (c_parser *parser)
+{
+ c_parser_consume_pragma (parser);
+ c_parser_skip_to_pragma_eol (parser);
+ return
On Jan 30, 2015, at 12:36 PM, Richard Biener richard.guent...@gmail.com wrote:
Ah, I kinda discounted that as it went by it seems. It seems most
other players go the other way, as the numbers get large, the first one
fixes, and then they add numbers at the bottom. Thanks.
You obviously
Let's drop libstdc++, this discussion is about a test that doesn't
really concern them.
On 30 January 2015 at 22:51, Jason Merrill ja...@redhat.com wrote:
The patch changes all the static_assert strings to , which is not very
useful; let's keep the macro.
Ok. How about this one? It reuses the
Am 30.01.2015 um 21:30 schrieb Jonny Grant j...@jguk.org:
On 30/01/15 17:09, pins...@gmail.com wrote:
On Jan 30, 2015, at 4:22 AM, Jonny Grant j...@jguk.org wrote:
Hello
When I checked out from the trunk I saw that various files had .C
capital extension. Its not a big
On January 30, 2015 9:18:57 PM CET, Richard Henderson r...@redhat.com wrote:
On 01/30/2015 12:12 PM, Mike Stump wrote:
On Jan 30, 2015, at 9:52 AM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Jan 30, 2015 at 09:45:26AM -0800, Mike Stump wrote:
I have a port that has:
(insn 47 46 48 18
On Jan 30, 2015, at 12:52 PM, Bernhard Reutner-Fischer rep.dot@gmail.com
wrote:
This last test is still puzzling me.
As it is to me. The reason it seems like they were going for in the code was
due to wrapping, but wrapping should only happen at something relating to the
bit size of the
On 01/30/2015 03:05 PM, Ville Voutilainen wrote:
-#define TRY(expr) static_assert (expr, #expr)
The patch changes all the static_assert strings to , which is not very
useful; let's keep the macro.
Jason
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64688
--- Comment #13 from Vladimir Makarov vmakarov at gcc dot gnu.org ---
Author: vmakarov
Date: Fri Jan 30 22:22:58 2015
New Revision: 220297
URL: https://gcc.gnu.org/viewcvs?rev=220297root=gccview=rev
Log:
2015-01-30 Vladimir Makarov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64872
--- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org ---
Created attachment 34630
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34630action=edit
Patch I am testing
The problem is that ICF merge profiles and profile merging sometimes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
--- Comment #16 from xur at google dot com ---
I did not follow the trunk version closely. But from reading the code, I
think the design is each DSO uses its own copy of gcov_* functions
(including gcov_open and gcov_read_counter) and accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #9 from Tom Tromey tromey at gcc dot gnu.org ---
Are you sure that class is not trivial which is why gcc is not warning about
it? C++11 does not really have pod and non-pod any more but rather trivial
and non-trivial and the rules
Hi!
As the following two testcases show, while we have avoid_complex_debug_insns
that decreases debug insn complexity after expansion is done, there is a
problem during expansion if the TER chains are too deep, because
simplify-rtx.c in some cases is inherently quadratic - does not like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64877
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc
On 30/01/15 17:09, pins...@gmail.com wrote:
On Jan 30, 2015, at 4:22 AM, Jonny Grant j...@jguk.org wrote:
Hello
When I checked out from the trunk I saw that various files had .C
capital extension. Its not a big issue.. but I wondered if they should
be .c like regular source files?
No
I have a port that has:
(insn 47 46 48 18 (parallel [
(unspec_volatile:DI [
(const_int 128 [0x80])
(const_int 6 [0x6])
] UNSPECV_SPECIAL_OP)
(set (mem/v:BLK (scratch:DI) [0 A8])
(unspec:BLK [
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64326
--- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org ---
make_forwarder_block is definitely wrong on not capping. But I do not see how
vectorizing can get us to a frequncy over FREQ_MAX? So probably some earlier
bug in there too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64617
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
CC||ubizjak at gmail
On 30 January 2015 at 21:59, Ville Voutilainen
ville.voutilai...@gmail.com wrote:
So, a new patch attached. The only change to the previous one is the change
to the trivial1.C test.
Oops. The No-template was borken and there was remnants of the macros
in commented
code. Let's try that again,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64878
--- Comment #1 from Sebastian Pop spop at gcc dot gnu.org ---
It fails with -O2 --param max-fsm-thread-paths=10 and does not fail with 9.
This is the thread that generates wrong code:
Registering FSM jump thread: (102, 6) incoming edge; (5,
On 01/28/2015 10:51 AM, Jason Merrill wrote:
On 01/28/2015 01:29 PM, Aldy Hernandez wrote:
+ /* It is rather unfortunate that Cilk creates trees this late +
(during gimplification). However, until this gets fixed, +
specially handle emitting DWARF for this new function and +
immediately clean
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64617
The patch was bootstrapped and tested on x86-64 and ppc64.
Committed as rev.220294.
2015-01-30 Vladimir Makarov vmaka...@redhat.com
PR target/64617
* lra-constraints.c
On 30 January 2015 at 19:46, Jason Merrill ja...@redhat.com wrote:
On 01/20/2015 09:27 AM, Ville Voutilainen wrote:
+#define YES2(type) TRY(std::is_trivialtype::value); \
+ TRY(std::is_trivialtype[]::value); \
TRY(std::is_trivialconst volatile type::value)
+YES2(void *);
+YES2(int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64810
--- Comment #21 from David Malcolm dmalcolm at gcc dot gnu.org ---
*** Bug 64873 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64877
--- Comment #3 from Tom Tromey tromey at gcc dot gnu.org ---
Oops, had the wrong gcc in $PATH.
That test case does warn:
pokyo. g++ -std=c++11 -c -Wall -Waddress -O2 x.cc
x.cc: In instantiation of ‘SDerived::S() [with Derived = T]’:
x.cc:19:8:
On 01/30/2015 12:12 PM, Mike Stump wrote:
On Jan 30, 2015, at 9:52 AM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Jan 30, 2015 at 09:45:26AM -0800, Mike Stump wrote:
I have a port that has:
(insn 47 46 48 18 (parallel [
(unspec_volatile:DI [
(const_int 128
On January 30, 2015 9:12:12 PM CET, Mike Stump mikest...@comcast.net wrote:
On Jan 30, 2015, at 9:52 AM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Jan 30, 2015 at 09:45:26AM -0800, Mike Stump wrote:
I have a port that has:
(insn 47 46 48 18 (parallel [
(unspec_volatile:DI [
On Fri, Jan 30, 2015 at 09:45:26AM -0800, Mike Stump wrote:
I have a port that has:
(insn 47 46 48 18 (parallel [
(unspec_volatile:DI [
(const_int 128 [0x80])
(const_int 6 [0x6])
] UNSPECV_SPECIAL_OP)
(set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64617
--- Comment #3 from Vladimir Makarov vmakarov at gcc dot gnu.org ---
Author: vmakarov
Date: Fri Jan 30 17:47:44 2015
New Revision: 220294
URL: https://gcc.gnu.org/viewcvs?rev=220294root=gccview=rev
Log:
2015-01-30 Vladimir Makarov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64349
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Hello!
Attached patch adds nonpic target requirement for some (obvious)
cases, where data access or PIC register setup confuses scan-asms.
2015-01-30 Uros Bizjak ubiz...@gmail.com
* gcc.target/i386/fuse-caller-save-rec.c: Require nonpic target.
*
On 01/20/2015 09:27 AM, Ville Voutilainen wrote:
+#define YES2(type) TRY(std::is_trivialtype::value); \
+ TRY(std::is_trivialtype[]::value); \
TRY(std::is_trivialconst volatile type::value)
+YES2(void *);
+YES2(int A::*);
Why would void *const volatile still be trivial?
Jason
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64879
Bug ID: 64879
Summary: ICE for -O3 when calling a transactional method from a
transaction inside a for loop
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53949
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
On 30 January 2015 at 20:25, Jason Merrill ja...@redhat.com wrote:
On 01/30/2015 01:13 PM, Ville Voutilainen wrote:
Why would void *const volatile still be trivial?
Ah. It isn't. YES and YES2 are macros, so YES2(void*) expands to
is_trivialconst volatile void*::value, which is true,
On Jan 30, 2015, at 9:52 AM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Jan 30, 2015 at 09:45:26AM -0800, Mike Stump wrote:
I have a port that has:
(insn 47 46 48 18 (parallel [
(unspec_volatile:DI [
(const_int 128 [0x80])
(const_int 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64878
--- Comment #2 from Sebastian Pop spop at gcc dot gnu.org ---
Jump threading is called twice as two separate passes, the miscompiled jump
thread during the first invocation is:
Registering FSM jump thread: (10, 114) incoming edge; (4, 93)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63923
iverbin at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
--- Comment #15 from Jan Hubicka hubicka at ucw dot cz ---
No. Each dso's gcov machinery is individually invoked. There should be no
cross-dso accessing of data (beyond the global chain of dso)
I am not saying my fix is correct, just lets me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64880
Bug ID: 64880
Summary: OpenACC gcc/g++ Discrepancy
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
We haven't been using this for a looong time. It never even gets defined.
Removed and committed to branch.
Aldy
commit a8076b015cad17538e369c153f8c7cf888433840
Author: Aldy Hernandez al...@redhat.com
Date: Tue Jan 27 11:24:53 2015 -0800
* dwarf2out.c (file_table_last_lookup): Remove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64311
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
On 01/30/2015 11:01 AM, Aldy Hernandez wrote:
We haven't been using this for a looong time. It never even gets defined.
Removed and committed to branch.
Aldy
Ughh, I'm having git rebase issues. I was missing part of the patch.
Here's the rest.
Committed to branch.
Aldy
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64878
--- Comment #3 from Sebastian Pop spop at gcc dot gnu.org ---
-fdbg-cnt=registered_jump_thread:44 passes
-fdbg-cnt=registered_jump_thread:45 fails
So this is the jump thread that produces the wrong code:
Registering FSM jump thread: (10, 114)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64717
--- Comment #6 from Gert-jan Los gerrit.los at gmail dot com ---
I want to confirm that all false warnings in my code are fixed by your patch.
Thanks.
On January 30, 2015 5:33:43 PM CET, Mike Stump mikest...@comcast.net wrote:
On Jan 29, 2015, at 7:16 PM, Andrew Pinski pins...@gmail.com wrote:
On Thu, Jan 29, 2015 at 6:58 PM, Mike Stump mikest...@comcast.net
wrote:
On Jan 29, 2015, at 4:15 PM, Joseph Myers jos...@codesourcery.com
wrote:
The
OK.
Jason
On 01/29/15 05:38, Rainer Orth wrote:
So I saw. If all else fails, we can still commit the (ugly/hard to
read) initial version, otherwise libgo won't build on Solaris before
some (quite recent) Solaris 11.2 patch, breaking bootstrap.
Having it work at all seems like a nice feature.
I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64873
David Malcolm dmalcolm at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
On 01/30/2015 01:13 PM, Ville Voutilainen wrote:
Why would void *const volatile still be trivial?
Ah. It isn't. YES and YES2 are macros, so YES2(void*) expands to
is_trivialconst volatile void*::value, which is true, whereas
is_trivialvoid* const volatile::value is false.
I think it
1 - 100 of 217 matches
Mail list logo
