[Bug libstdc++/62318] optimization of string searches using Nigel Horspool's Boyer-Moore-Horpool algorithm

2014-09-21 Thread jmichae3 at yahoo dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62318

--- Comment #6 from Jim Michaels  ---
ummm. I could get personal permission to use the algorithm. but that does not
give gnu permission to use the algorithm. that's why I posted this here.  that
does not necessarily mean I could post the algorithm to GNU, because I am not
associated with GNU (I don't intend to bristle someone), I am just a user of
gcc trying to make a difference in speed of the compiler. I have an i7-3970x
64GB RAM on windows and I am doing file processing that should *not* take 5
minutes for a 1ast timing, bare or MT19937 random number writes I can do
86.437894MB/s on a hard drive. but my programs that do std::string processing
are many many times slower. 

other compilers out there are just as bad. I was hoping to make a dent in this
performance sluggishness... I am just saying this cpu I have should blaze a
trail. most of that program is a fair amount of string processing, lookups in
vectors, vector structures, etc. I avoided using any of my own classes.

most of this stuff is processed in RAM, so it's got to be the (I got the O()
notation wrong) algorithm. Boyer-Moore is a very good general string search
algorithm (but only for 8 and 16-bit characters) that's been around for at
least 20 years. should not be hard at all to convert. I might do it to my
personal compiler myself if the ACM article and permission doesn't cost too
much. I am using mingw-w64 windows x64 and x32 target, windows x64 host port of
gcc. 
http://www.cs.utexas.edu/users/moore/publications/fstrpos.pdf
http://www.cs.utexas.edu/users/moore

my only concern is that if I were to post the algorithm, me not being in the
GNU organization, GNU would still have to get separate permission, first. I
could say "OK, I've got it, get permission, then I will post the patch." but I
write commercial code. so then there's the whole FSF thing and "tainted code"
(I intend to distribute my source code and some libraries if I am allowed).

someone said Horspool involved startup cost building lookup tables and therein
lies the difficulty, so I got that part wrong I just found out. it is used in
std::search. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3905.html

I already have code which converts a stream of bytes to UTF-8 and back based on
http://doc.cat-v.org/bell_labs/utf-8_history

but that's beside the point.

I would be very happy to just jump in and render a patch. I just wanted to get
the permissions thing done proper. it's a VERY SIMPLE algorithm, all of about
10-20 lines. looked like a piece of cake. I am just concerned about my
"tainting" of your code (?) and permissions, etc.

is this something that I, not associated with GNU, can do? yes, no? my guess is
no. that is why I made this request. I know *you* can do it without causing
problems.

http://www.boost.org/doc/libs/1_50_0/libs/algorithm/doc/html/algorithm/Searching.html

however, boyer-moore would not be recommendable for u32string, since it would
allocate an array that has 2^32 32-bit (16GB) elements as an "alphabet" (part
of the startup costs). 65536 16-bit (128KB) elements for u16string, 256 bytes
for 8-bit char_t. you get the idea. 32-bit targets would obviously fail to
compile, and significant memory loss on 64-bit systems, and they would fail to
run on average joe's box.

so I guess instead of horspool's algorithm for strings, your O(m+n) algorithm
in strstr() would be a more effective replacement. please.

who at the FSF deals with permissions?

not sure if this applies: it's for "small alphabets" (as in DNA):
http://www.cs.utexas.edu/users/moore/publications/sustik-moore.pdf

the US Department of Commerce regulates hashes I think such as Rabin-Karp above
a certain number of bits. when you start getting to char16_t and char32_t that
hash number of bits due to multiplies has already reached 32 bits. sigh. this
is why computers are slow.  I don't know if strstr is in this category. 

maybe std::string.find() should be left the way it is.

maybe some unit-testing on that small-alphabet thing would be interesting, but
I am unsure if it would have the same memory-use problem for char32_t as
Boyer-Moore.

[Bug ipa/61283] [5 regression] SEGV in pass_ipa_comdats::execute

2014-09-21 Thread hp at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61283

--- Comment #4 from Hans-Peter Nilsson  ---
(In reply to Jan Hubicka from comment #3)
> Does this still reproduce?

It still does at least for MMIX as described, at r215419.

[Bug ipa/61283] [5 regression] SEGV in pass_ipa_comdats::execute

2014-09-21 Thread hp at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61283

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED

[Bug pch/63319] New: [5 Regression] ICE: Segmentation fault building qt5 with pch

2014-09-21 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63319

Bug ID: 63319
   Summary: [5 Regression] ICE: Segmentation fault building qt5
with pch
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pch
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org

markus@x4 corelib % /var/tmp/gcc_test/usr/local/bin/g++ -c -march=amdfam10 -O2
-g -fvisibility=hidden -fvisibility-inlines-hidden -std=c++0x -W -fPIC qhash.ii
tools/qhash.cpp: In function ‘unsigned int _mm_crc32_u8(unsigned int, unsigned
char)’:
tools/qhash.cpp:803:1: internal compiler error: Segmentation fault
 }
 ^
0xbbee0f crash_signal
../../gcc/gcc/toplev.c:340
0x72516d c_tree_chain_next
../../gcc/gcc/c-family/c-common.h:1230
0x72516d gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:159
0x9b44e5 ggc_mark_root_tab
../../gcc/gcc/ggc-common.c:133
0x9b49a0 ggc_mark_roots()
../../gcc/gcc/ggc-common.c:152
0x7e72f4 ggc_collect()
../../gcc/gcc/ggc-page.c:2173
Please submit a full bug report,
with preprocessed source if appropriate.

preprocessed source has at the beginning:
#pragma GCC pch_preprocess "./.pch/Qt5Core.gch/c++"
That file size is 63Mb.

gdb shows:
process 25582 is executing new program:
/var/tmp/gcc_test/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/cc1plus
tools/qhash.cpp: In function ‘unsigned int _mm_crc32_u8(unsigned int, unsigned
char)’:
tools/qhash.cpp:803:1: internal compiler error: in
tree_node_structure_for_code, at tree.c:407
 }
 ^
0xdf8c3b tree_node_structure_for_code
../../gcc/gcc/tree.c:407
0xdf8c3b tree_node_structure(tree_node const*)
../../gcc/gcc/tree.c:3271
0x7254ff gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:165
0x9b44e5 ggc_mark_root_tab
../../gcc/gcc/ggc-common.c:133
0x9b49a0 ggc_mark_roots()
../../gcc/gcc/ggc-common.c:152
0x7e72f4 ggc_collect()
../../gcc/gcc/ggc-page.c:2173
Please submit a full bug report,
with preprocessed source if appropriate.

valgrind shows:
==25604== Invalid read of size 1
==25604==at 0x72516D: c_tree_chain_next (c-common.h:1230)
==25604==by 0x72516D: gt_ggc_mx_lang_tree_node(void*) (gt-cp-tree.h:159)
==25604==by 0x9B44E5: ggc_mark_root_tab(ggc_root_tab const*)
(ggc-common.c:133)
==25604==by 0x9B49A0: ggc_mark_roots() (ggc-common.c:152)
==25604==by 0x7E72F4: ggc_collect() (ggc-page.c:2173)
==25604==by 0xB0728A: execute_one_pass(opt_pass*) (passes.c:2191)
==25604==by 0xB07715: execute_pass_list_1(opt_pass*) (passes.c:2203)
==25604==by 0xB07768: execute_pass_list(function*, opt_pass*)
(passes.c:2214)
==25604==by 0xB05F84: do_per_function_toporder(void (*)(function*, void*),
void*) (passes.c:1521)
==25604==by 0xB07D46: execute_ipa_pass_list(opt_pass*) (passes.c:2548)
==25604==by 0x866317: ipa_passes (cgraphunit.c:2017)
==25604==by 0x866317: symbol_table::compile() (cgraphunit.c:2136)
==25604==by 0x8680F7: symbol_table::finalize_compilation_unit()
(cgraphunit.c:2288)
==25604==by 0x650BBA: cp_write_global_declarations() (decl2.c:4666)
==25604==  Address 0x1c10018 is not stack'd, malloc'd or (recently) free'd
==25604== 
tools/qhash.cpp: In function ‘unsigned int _mm_crc32_u8(unsigned int, unsigned
char)’:
tools/qhash.cpp:803:1: internal compiler error: Segmentation fault

Without "-g" the issue goes away.
Not sure how to reduce this issue further. Hints welcome.

[Bug libstdc++/62318] optimization of string searches using Nigel Horspool's Boyer-Moore-Horpool algorithm

2014-09-21 Thread redi at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62318

--- Comment #7 from Jonathan Wakely  ---
I don't understand your concern, you don't need anyone's permission to use a
published algorithm. A specific implementation of the algorithm would be
covered by copyright, but not the abstract algorithm.

If you want to contribute code to GCC then there are legal prerequisites (see
https://gcc.gnu.org/contribute.html) but that's not to do with permission to
use an algorithm. If you wanted to contribute an implementation you would need
to meet those prerequisites. Glibc has similar requirements.

Otherwise just be happy that glibc already does better than a linear search and
libstdc++ will be implementing std::search soon.

[Bug ada/63225] ada bootstrap failure when -fno-inline in STAGE1_CFLAGS

2014-09-21 Thread ebotcazou at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63225

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-09-21
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Botcazou  ---
It's because we have inter-unit inlining in the Ada compiler even w/o LTO.

[Bug target/50807] [avr] Constructor writing to RAM for variable in Flash

2014-09-21 Thread gjl at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50807

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.9.2
 Resolution|--- |WORKSFORME
   Target Milestone|--- |4.9.0

--- Comment #6 from Georg-Johann Lay  ---
Works in 4.9.

[Bug c++/63320] New: [5 Regression] bogus ‘this’ was not captured for this lambda function error

2014-09-21 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63320

Bug ID: 63320
   Summary: [5 Regression] bogus ‘this’ was not captured for this
lambda function error
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org

Happened building qt-creator:

markus@x4 coreplugin % cat windowsupport.ii
class A {
  static void addWindow();
  static void activateWindow(void *);
};
void A::addWindow() {
  int* action {};
  [action] { activateWindow(action); };
}

markus@x4 coreplugin % g++ -c -std=c++14 windowsupport.ii
windowsupport.ii: In lambda function:
windowsupport.ii:7:35: error: ‘this’ was not captured for this lambda function
   [action] { activateWindow(action); };
   ^
(4.9 and 4.8 are fine)
markus@x4 coreplugin % g++ -c -std=c++11 windowsupport.ii
markus@x4 coreplugin % icpc -c -std=c++11 windowsupport.ii
markus@x4 coreplugin % clang++ -w -c -std=c++11 windowsupport.ii
markus@x4 coreplugin %

[Bug target/63321] New: [SH] Unused T bit result of shll / shlr insns

2014-09-21 Thread olegendo at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63321

Bug ID: 63321
   Summary: [SH] Unused T bit result of shll / shlr insns
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*

The following examples resemble code that is usually used when implementing
pointer tagging (storing meta info in always-zero bits of a pointer variable). 
The shll / shr insns shift the MSB / LSB out into the T bit.  However, the T
bit value is lost and redundant MSB / LSB extractions remain in the code.

unsigned int foo (unsigned int);

unsigned int test2 (unsigned int x)
{
  unsigned int xx = x >> 1;
  if (x & 1)
return foo (xx);
  else
return xx;
}

/*
mov r4,r1
shlrr1
mov r4,r0
tst #1,r0
bf/s.L5
mov r1,r0
rts
nop
.align 1
.L5:
mov.l   .L6,r0
jmp @r0
mov r1,r4

better:
shlrr4
bt  .L5
rts
mov r4,r0
.L5:
mov.l   .L6,r0
jmp @r0
nop
*/



void test2_1 (unsigned int x, unsigned int* y)
{
  y[0] = x >> 1;
  y[1] = x & 1;
}

/*
mov r4,r1
mov r4,r0
shlrr1
and #1,r0
mov.l   r1,@r5
rts
mov.l   r0,@(4,r5)

better:
shlrr4
movtr0
mov.l   r4,@r5
rts
mov.l   r0,@(4,r5)
*/

unsigned int test3 (unsigned int x)
{
  unsigned int xx = x << 1;
  if (x & (1 << 31))
return foo (xx);
  else
return xx;
}

/*
cmp/pz  r4
mov r4,r0
bf/s.L13
add r0,r0
rts
nop
.align 1
.L13:
mov r0,r4
mov.l   .L14,r0
jmp @r0
nop

better:
shllr4
bt  .L13
rts
mov r4,r0
.L13:
mov.l   .L14,r0
jmp @r0
nop
*/

void test3_1 (unsigned int x, unsigned int* y)
{
  y[0] = x << 1;
  y[1] = x >> 31;
}

/*
mov r4,r1
shllr4
add r1,r1
movtr4
mov.l   r1,@r5
rts
mov.l   r4,@(4,r5)

better:
shllr4
movtr0
mov.l   r4,@r5
rts
mov.l   r0,@(4,r5)
*/

It seems that combine doesn't try to combine those adjacent insns into a
parallel, which could be used to implement that kind of patterns.  An
alternative is to do a manual combining/peepholing of insns in the split pass
after combine, as it is done for other insns.

[Bug c++/63320] [5 Regression] bogus ‘this’ was not captured for this lambda function error

2014-09-21 Thread trippels at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63320

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Markus Trippelsdorf  ---
Started with r210292.

[Bug libstdc++/63322] New: std::atomic where T is not trivially copyable should be disabled.

2014-09-21 Thread roman at binarylife dot net 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63322

Bug ID: 63322
   Summary: std::atomic where T is not trivially copyable
should be disabled.
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roman at binarylife dot net

[atomic.types.generic]: There is a generic class template atomic. The type
of the template argument T shall be trivially copyable (3.9).

It would be helpful if std::atomic disallowed wrong T because the generated
code is obviously makes no sense (at least for x86_64): bar() returns a
hard-coded NaN.

$ cat test.cc 
#include 

long double foo(const long double& f) noexcept;

struct X {
  X() = default;
  X(X const& o) noexcept : f(foo(o.f)) {}
  X& operator=(X const& o) noexcept { f = foo(o.f); return *this; }
  long double f = foo(0);
};

extern std::atomic a;

long double bar() { a.load().f; }

$ g++ -c -O2 --save-temps -std=c++11 test.cc && echo ok
ok

$ cat test.s 
.file   "test.cc"
.section.text.unlikely,"ax",@progbits
.LCOLDB2:
.text
.LHOTB2:
.p2align 4,,15
.globl  _Z3barv
.type   _Z3barv, @function
_Z3barv:
.LFB330:
.cfi_startproc
fldz
subq$24, %rsp
.cfi_def_cfa_offset 32
movq%rsp, %rdi
fstpt   (%rsp)
call_Z3fooRKe
fstp%st(0)
movl$5, %esi
movl$a, %edi
call__atomic_load_16
flds.LC1(%rip)
addq$24, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE330:
.size   _Z3barv, .-_Z3barv
.section.text.unlikely
.LCOLDE2:
.text
.LHOTE2:
.section.rodata.cst4,"aM",@progbits,4
.align 4
.LC1:
.long   2143289344
.ident  "GCC: (GNU) 5.0.0 20140920 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug libstdc++/63322] std::atomic where T is not trivially copyable should be disabled.

2014-09-21 Thread redi at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63322

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #1 from Jonathan Wakely  ---
This is hard to enforce because we don't support std::is_trivially_copyable.

[Bug target/58757] Advertise the lack of denormal support on alpha without -mieee

2014-09-21 Thread ubizjak at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58757

--- Comment #2 from Uroš Bizjak  ---
As the author of the testcase kindly advises:

/* Test that the smallest positive value is not 0. This needs to be true
   even when denormals are not supported, so we do not pass any flag
   like -mieee.  If it fails on alpha, see PR 58757.  */

Well, the testcase does fail on alpha:

Program received signal SIGFPE, Arithmetic exception.
0x000127ac in main () at
/space/homedirs/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/c11-true_min-1.c:14
14if (f == 0 || d == 0 || l == 0)

(gdb) p f
$1 = 1.40129846e-45
(gdb) p d
$2 = 4.9406564584124654e-324
(gdb) p l
$3 = 

   0x000127a4 <+84>:fmov$f10,$f10
=> 0x000127a8 <+88>:cmpteq  $f11,$f10,$f10
   0x000127ac <+92>:fbne$f10,0x127ec 

f100(raw 0x)
f112.6524947387065904e-315  (raw 0x2000)

[Bug target/58757] Advertise the lack of denormal support on alpha without -mieee

2014-09-21 Thread glisse at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58757

--- Comment #3 from Marc Glisse  ---
(In reply to Uroš Bizjak from comment #2)
> Well, the testcase does fail on alpha:

Thanks. In the original testcase (
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00875.html ) I was xfailing on
alpha, but Joseph asked me not to xfail it until someone has actually observed
the failure. Could you please xfail it (or whatever similar option you prefer)
until this PR is addressed? (Unless you want to fix this PR, of course ;-)

[Bug target/55212] [SH] Switch from IRA to LRA

2014-09-21 Thread kkojima at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #25 from Kazumoto Kojima  ---
Created attachment 33524
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33524&action=edit
Reduced test case for ICE in assign_by_spill

I've looked into what is going on for the ICE in assign_by_spill.
The above test case ICEs on sh-elf with
"-m4 -ml -O1 -ftree-parallelize-loops=4 -ftree-vectorize".
.ira and .reload dumps show that the load and store insns

   42: r208:SI=[r202:SI+r185:SI]
   43: [r207:SI+r200:SI]=r218:HI // r218 = subreg:HI r208

are reloaded like as

   73: r217:SI=r200:SI
   79: r223:SI=r185:SI
   74: r218:HI=[r202:SI+r223:SI]
   43: [r207:SI+r217:SI]=r218:HI

and R0_REGS is assigned to both r217 and r223 because the only
register R0 can be used as the index register on SH.  .reload says
that the original insn 42 is deleted and the source operand r218
of insn 43 is substituted with its equiv [r202:SI+r185:SI].
It seems that it works also for SH if reload insn 73 was inserted
at just before insn 43.  I've attached .reload dump for this too.

[Bug target/55212] [SH] Switch from IRA to LRA

2014-09-21 Thread kkojima at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #26 from Kazumoto Kojima  ---
Created attachment 33525
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33525&action=edit
.reload dump file

[Bug target/55212] [SH] Switch from IRA to LRA

2014-09-21 Thread kkojima at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #27 from Kazumoto Kojima  ---
Created attachment 33526
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33526&action=edit
A trial patch

It disables equiv substitution when the equiv includes some reg
assigned to a small register class.  I hope that it makes the issue
a bit clearer, even if it doesn't the right thing.

[Bug target/55212] [SH] Switch from IRA to LRA

2014-09-21 Thread kkojima at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #28 from Kazumoto Kojima  ---
Created attachment 33527
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33527&action=edit
Another reduced test case (with "-m4 -ml -O2 -std=gnu99")

Here is a test case for the ICE in assign_by_spill which looks
caused by another reason.
.reload dump says that the problematic insn is something like

  107: {r166:SF=[r942:SI+r943:SI];use :PSI;clobber r784:SI;}

and

  Creating newreg=942 from oldreg=374, assigning class R0_REGS to address
r942
  Creating newreg=943, assigning class GENERAL_REGS to base + disp r943
   Change to class R0_REGS for r943

which means that R0_REGS is assigned to both r942 and r943.

[Bug target/55212] [SH] Switch from IRA to LRA

2014-09-21 Thread kkojima at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #29 from Kazumoto Kojima  ---
Created attachment 33528
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33528&action=edit
A trial patch

The patch is to refrain from changing to class R0_REGS for r943.

With the above 2 patches, the remained test case failing with the ICE
in assign_by_spill is gcc.dg/pr38338.c which uses extra-ordinary
__builtin_apply_args and __builtin_apply builtins.  I can't get
what is going on that case yet.

[Bug c++/61825] [5 regression] g++.dg/cpp0x/static_assert9.C FAILs

2014-09-21 Thread hp at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61825

--- Comment #9 from Hans-Peter Nilsson  ---
Seems to be fixed, but I'm leaving the closing step to the reporter (Rainer).

[Bug tree-optimization/63255] [5.0 regression] FAIL: gcc.dg/lto/ipareference2 c_lto_ipareference2_0.o-c_lto_ipareference2_1.o execute -O1 -flto -flto-partition=1to1 -fwhole-program

2014-09-21 Thread hp at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63255

--- Comment #4 from Hans-Peter Nilsson  ---
Seems to be fixed, but I'm leaving the closing step to the reporter (Andreas).

[Bug c++/63323] New: "confused by earlier errors, bailing out" with no other errors

2014-09-21 Thread tavianator at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63323

Bug ID: 63323
   Summary: "confused by earlier errors, bailing out" with no
other errors
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tavianator at gmail dot com

Created attachment 33529
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33529&action=edit
Preprocessed source

The following file gives a "confused by earlier errors, bailing out" error
message, with no previous errors printed, when compiled with
-fsanitize=undefined:

$ cat confused.cpp
#include 
#include 

int
main()
{
  std::unique_ptr ptr{new int};
  std::map> map;
  map.insert({0, std::move(ptr)});
  return 0;
}
$ g++ -std=c++11 -fsanitize=undefined confused.cpp
‘
/usr/include/c++/4.9.1/ext/new_allocator.h:120: confused by earlier errors,
bailing out

Without the -fsanitize=undefined, it points to the actual error, which is fixed
by using std::make_pair instead of a braced initializer as the argument to
insert().

[Bug c/63324] New: hexidecimal integer constant and addition

2014-09-21 Thread kargl at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63324

Bug ID: 63324
   Summary: hexidecimal integer constant and addition
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org

#include 

int
main(void)
{
int i;
i = 0x3ffe+63; printf("%x\n", i);
return 0;
}

% gcc47 -c ~/tmp/a.c
/home/kargl/tmp/a.c: In function 'main':
/home/kargl/tmp/a.c:7:6: error: invalid suffix "+63" on integer constant

+ is a binary operator. 0x3ffe is a hexidecimal constant and 63
is a decimal constant.

[Bug c/44272] Wrong interpretation of hex constant as floating point value.

2014-09-21 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44272

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #4 from Andrew Pinski  ---
Dup of bug 3885.

*** This bug has been marked as a duplicate of bug 3885 ***

[Bug c/44272] Wrong interpretation of hex constant as floating point value.

2014-09-21 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44272

Andrew Pinski  changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #3 from Andrew Pinski  ---
*** Bug 63324 has been marked as a duplicate of this bug. ***

[Bug c/63324] hexidecimal integer constant and addition

2014-09-21 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63324

--- Comment #2 from Andrew Pinski  ---
Actually bug 3885.

*** This bug has been marked as a duplicate of bug 3885 ***

[Bug c/63324] hexidecimal integer constant and addition

2014-09-21 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63324

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
Dup of bug 44272.

*** This bug has been marked as a duplicate of bug 44272 ***

[Bug c/3885] Incorrect "invalid suffix on integer constant" error

2014-09-21 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3885

Andrew Pinski  changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #12 from Andrew Pinski  ---
*** Bug 63324 has been marked as a duplicate of this bug. ***

[Bug c/3885] Incorrect "invalid suffix on integer constant" error

2014-09-21 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3885

Andrew Pinski  changed:

   What|Removed |Added

 CC||draqsn at mail dot ru

--- Comment #13 from Andrew Pinski  ---
*** Bug 44272 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/63325] New: [5.0 regression] ICE fold check: original tree changed by fold

2014-09-21 Thread dimhen at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63325

Bug ID: 63325
   Summary: [5.0 regression] ICE fold check: original tree changed
by fold
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com

r215401 PASS
r215427, r215444 FAIL

Fedora 20 / x86_64

$ configure --enable-checking=fold
$ make
[...]
/home/dimhen/build/gcc_current/./gcc/xgcc
-B/home/dimhen/build/gcc_current/./gcc/
-B/usr/local/gcc_current/x86_64-unknown-linux-gnu/bin/
-B/usr/local/gcc_current/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/gcc_current/x86_64-unknown-linux-gnu/include -isystem
/usr/local/gcc_current/x86_64-unknown-linux-gnu/sys-include-g -O2 -m32 -O2 
-g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -fpic -mlong-double-80 -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -fpic -mlong-double-80 -I. -I. -I../../.././gcc
-I/home/dimhen/src/gcc_current/libgcc -I/home/dimhen/src/gcc_current/libgcc/.
-I/home/dimhen/src/gcc_current/libgcc/../gcc
-I/home/dimhen/src/gcc_current/libgcc/../include
-I/home/dimhen/src/gcc_current/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT
-DHAVE_CC_TLS  -DUSE_TLS -o generic-morestack.o -MT generic-morestack.o -MD -MP
-MF generic-morestack.dep  -c
/home/dimhen/src/gcc_current/libgcc/generic-morestack.c -fvisibility=hidden
-DHIDE_EXPORTS
/home/dimhen/src/gcc_current/libgcc/generic-morestack.c: In function
'__morestack_block_signals':
/home/dimhen/src/gcc_current/libgcc/generic-morestack.c:675:3: internal
compiler error: fold check: original tree changed by fold
   else if (pthread_sigmask)
   ^
0x9e0512 fold_check_failed
/home/dimhen/src/gcc_current/gcc/fold-const.c:14554
0x9e0407 fold(tree_node*)
/home/dimhen/src/gcc_current/gcc/fold-const.c:14531
0x6f9719 c_fully_fold_internal
/home/dimhen/src/gcc_current/gcc/c-family/c-common.c:1309
0x6f8865 c_fully_fold(tree_node*, bool, bool*)
/home/dimhen/src/gcc_current/gcc/c-family/c-common.c:1101
0x6d4ada c_parser_condition
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:5052
0x6d4b38 c_parser_paren_condition
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:5069
0x6d4f01 c_parser_if_statement
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:5170
0x6d43b9 c_parser_statement_after_labels
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:4888
0x6d4e61 c_parser_else_body
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:5144
0x6d4f8d c_parser_if_statement
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:5178
0x6d43b9 c_parser_statement_after_labels
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:4888
0x6d3e76 c_parser_compound_statement_nostart
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:4650
0x6d38a1 c_parser_compound_statement
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:4487
0x6ce7d2 c_parser_declaration_or_fndef
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:1946
0x6cd462 c_parser_external_declaration
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:1416
0x6cd0e5 c_parser_translation_unit
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:1303
0x6ed98a c_parse_file()
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:14322
0x7533a7 c_common_parse_file()
/home/dimhen/src/gcc_current/gcc/c-family/c-opts.c:1043
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[5]: *** [generic-morestack.o] Error 1
make[5]: Leaving directory
`/home/dimhen/build/gcc_current/x86_64-unknown-linux-gnu/32/libgcc'
make[4]: *** [multi-do] Error 1
make[4]: Leaving directory
`/home/dimhen/build/gcc_current/x86_64-unknown-linux-gnu/libgcc'
make[3]: *** [all-multi] Error 2
make[3]: Leaving directory
`/home/dimhen/build/gcc_current/x86_64-unknown-linux-gnu/libgcc'
make[2]: *** [all-stage1-target-libgcc] Error 2
make[2]: Leaving directory `/home/dimhen/build/gcc_current'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/dimhen/build/gcc_current'
make: *** [all] Error 2

[Bug rtl-optimization/63325] [5.0 regression] ICE fold check: original tree changed by fold

2014-09-21 Thread dimhen at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63325

Dmitry G. Dyachenko  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Dmitry G. Dyachenko  ---
start FAIL r215409

[Bug c/63326] New: pragma GCC causes wrong code generation

2014-09-21 Thread dietmar.schind...@manroland-web.com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326

Bug ID: 63326
   Summary: pragma GCC causes wrong code generation
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dietmar.schind...@manroland-web.com

Created attachment 33530
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33530&action=edit
preprocessed file

The following command generates wrong code, returning 1 instead of 0 (as if the
pragma line ended the statement in which it is placed).

raeksrv1:~/bin/so/c> /tmp/usr/local/bin/gcc -v -save-temps bug.c -o bug 
Using built-in specs.
COLLECT_GCC=/tmp/usr/local/bin/gcc
COLLECT_LTO_WRAPPER=/tmp/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.9.1/configure --enable-plugin --disable-libsanitizer
: (reconfigured) ../gcc-4.9.1/configure --enable-plugin --enable-languages=c
--disable-libsanitizer : (reconfigured) ../gcc-4.9.1/configure --enable-plugin
--enable-languages=c --disable-libsanitizer --disable-libcilkrts
Thread model: posix
gcc version 4.9.1 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'bug' '-mtune=generic'
'-march=x86-64'
 /tmp/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/cc1 -E -quiet
-v -iprefix /tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/ bug.c
-mtune=generic -march=x86-64 -fpch-preprocess -o bug.i
ignoring nonexistent directory
"/tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../x86_64-unknown-linux-gnu/include"
ignoring duplicate directory
"/tmp/usr/local/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/include"
ignoring duplicate directory
"/tmp/usr/local/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/include-fixed"
ignoring nonexistent directory
"/tmp/usr/local/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/include
 /tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/include-fixed
 /usr/local/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'bug' '-mtune=generic'
'-march=x86-64'
 /tmp/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/cc1
-fpreprocessed bug.i -quiet -dumpbase bug.c -mtune=generic -march=x86-64
-auxbase bug -version -o bug.s
GNU C (GCC) version 4.9.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.1, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (GCC) version 4.9.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.9.1, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: aa505e323dbffe0cb500ba62f983d917
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'bug' '-mtune=generic'
'-march=x86-64'
 as -v --64 -o bug.o bug.s
GNU assembler version 2.20.1 (i486-linux-gnu) using BFD version (GNU Binutils
for Debian) 2.20.1-system.20100303
COMPILER_PATH=/tmp/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/:/tmp/usr/local/bin/../libexec/gcc/
LIBRARY_PATH=/tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/:/tmp/usr/local/bin/../lib/gcc/:/tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'bug' '-mtune=generic'
'-march=x86-64'
 /tmp/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/collect2
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o bug
/usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o
/tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/crtbegin.o
-L/tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1
-L/tmp/usr/local/bin/../lib/gcc
-L/tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../.. bug.o
-lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed
/tmp/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.1/crtend.o
/usr/lib/../lib64/crtn.o

[Bug c/63326] pragma GCC causes wrong code generation

2014-09-21 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
#pragma are considered statements.