[Bug c++/65890] [C++03]sizeof(qualified-id) accepted when the operand denotes a non-static member

[frankhb1989 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65890

--- Comment #7 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to frankhb1989 from comment #5)
> > Mainly for testing of the conformance.
> 
> I don't understand what this means. Testing what? G++? G++ does not exist
> for you to test its conformance to a standard. Most users don't care about
> slavish conformance to a defective specification, they want a useful
> compiler.
>

Ok, since there is no "strictly conforming program" concept in ISO C++ as it in
ISO C, I'd better to clarify, the direct point is portability of the legacy
user code. Checking and ensuring the code (carefully kept undefined behavior or
"no diagnostics required" away) to be standard-compliant is one aspect of
usefulness of the compiler which provides "standard" modes. How can I do if
'g++ -std=c++03 -pedantic-errors' behaves different than other C++03-conforming
compilers compiling the ill-formed C++03 code, besides to drop the code away? 

> > Although it is treated a defect of
> > the design and has been changed later, the old rules are still well-defined
> > and the published standard itself is consistent. So if I did not get wrong
> > about the purpose of '-std=', this should be a bug. Whether it is worth
> > being fixed is another problem.
> 
> You are wrong about how -std options work. We incorporate dozens of DRs into
> all modes, instead of making them only apply to later standard modes.
> 

The manual says nothing about this. It tells me "to obtain all the diagnostics
required by the standard, you should also specify -pedantic (or
-pedantic-errors if you want them to be errors rather than warnings)". I
thought the "standard" here is one of the published ones. And there seems to be
no separate options to control the features in individual DRs. If the compiler
frontend does right (by design) as you said, this is a documentation issue,
since I am really confused about what g++ are allowed to do.
Now it seems I'd better simply not rely on these -std options of g++ for these
works.

> > On the other hand, I'd debate the resolution of this CWG issue is not pure
> > improvement. There could be a trick to distinguish static and non-static
> > data members through SFINAE on expressions like 'sizeof(&(C::x))'. It is
> > broken now.
> 
> SFINAE in C++03 was not nearly as useful, and doesn't work for private
> members. The language is more useful now, there is no reason to hobble it
> with a foolish consistency to a defective design.

Yes, it is obviously not so useful as C++11/14/1z. But can we just get rid of
C++98/03 totally for this reason? For this issue, the (current) result is, 'g++
-std=c++03 -pedantic-errors' actually implements a dialect of C++03 with some
subtle "patches" in the standard, which is difficult in many aspects even to
experienced users. And even this is a resolved defect, the design of these
related features in the language is still arguably more or less defective. The
latter is nothing to do with g++ directly, though.

[Bug target/54236] [SH] Improve addc and subc insn utilization

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54236

--- Comment #13 from Oleg Endo  ---
Author: olegendo
Date: Tue May 19 08:00:41 2015
New Revision: 223346

URL: https://gcc.gnu.org/viewcvs?rev=223346&root=gcc&view=rev
Log:
gcc/
PR target/54236
* config/sh/sh.md (*round_int_even): New insn_and_split and
accompanying new unnamed split.

gcc/testsuite/
PR target/54236
* gcc.target/sh/pr54236-2.c: Adjust expected insn counts.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/sh/pr54236-2.c

[Bug c/66198] New: base on aarch64 compiler , fdo optimazition produec wrong result

[huangcunjian at huawei dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66198

Bug ID: 66198
   Summary: base on aarch64 compiler , fdo optimazition produec
wrong result
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: huangcunjian at huawei dot com
  Target Milestone: ---

[Bug target/66136] AArch64 geniterators.sh relies on GNU sed syntax, causing build failure on FreeBSD and probably Mac

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136

Richard Earnshaw  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #6 from Richard Earnshaw  ---
Ed,

Could you confirm this works with the standard FreeBSD Awk?

[Bug middle-end/66198] base on aarch64 compiler , fdo optimazition produec wrong result

[huangcunjian at huawei dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66198

--- Comment #1 from huangcunjian  ---
  gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/gcc/aarch64-oe-linux/4.9.2/lto-wrapper
Target: aarch64-oe-linux

command:
gcc -O2 -w   test.c   -fprofile-generate  -o tmp1
result_1=`./tmp1`

gcc -w   -O2 -fbranch-probabilities  -fprofile-use  -lm test.c -o tmp2
result_2=`./tmp2`

actual result:
result_1:checksum = 859D9AAE result_2:checksum = 7DDB417E

expect result:
result_1 and result_2 value is same

[Bug middle-end/66198] base on aarch64 compiler , fdo optimazition produec wrong result

[huangcunjian at huawei dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66198

--- Comment #2 from huangcunjian  ---
Created attachment 35564
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35564&action=edit
testcase context

[Bug c/66198] base on aarch64 compiler , fdo optimazition produce wrong result

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66198

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-05-19
 Ever confirmed|0   |1

--- Comment #3 from Richard Earnshaw  ---
The testcase uses RAR format, which is not free software.  Please use a more
acceptable compression format (if compression is needed at all).

[Bug middle-end/66110] uint8_t memory access not optimized

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110

--- Comment #15 from rguenther at suse dot de  ---
On Mon, 18 May 2015, kevin at koconnor dot net wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110
> 
> --- Comment #12 from Kevin OConnor  ---
> (In reply to Andreas Schwab from comment #11)
> > Since typedef does not create a new type the effect of uint8_t is exactly
> > the same as the type it is defined from.  Thus if uint8_t is defined from
> > unsigned char then uint8_t is a character type.
> 
> Yes, of course.  My point is that gcc does not need to define uint8_t /
> __UINT8_TYPE__ as 'unsigned char'.  Instead it could define it as a new 
> integer
> type (eg, __gcc_uint8_t) that is an 8-bit integer that does not alias.

Yes, agreed.  Like {signed,unsigned,} __gcc_int8_t or so...

> As before, I understand if the cost of doing this is too high, but it's
> unfortunate that there currently does not appear to be any way to define a
> pointer to an 8-bit integer that doesn't alias.

Another possibility would be to introduce an attribute similar to
may_alias, "not_alias" so you can do

typedef unsigned char uint8_t __attribute__((no_alias));

or sth like that.  As that wouldn't alias with

typedef unsigned char my_uint8_t __attribute__((no_alias));

the effects might be surprising though.

[Bug c/66198] base on aarch64 compiler , fdo optimazition produce wrong result

[huangcunjian at huawei dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66198

--- Comment #4 from huangcunjian  ---
Created attachment 35565
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35565&action=edit
testcase context

[Bug lto/66196] Wrong type incompatibility warning for -flto and C

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66196

--- Comment #1 from Richard Biener  ---
To handle unions specially we'd need to "sort" their fields in some way before
doing the comparison (we certainly don't want to do a N^2 compare).  We compare
field-decl offsets and types which should take care of the memory layout
(yes, not alignment but I hardly see where that matters for structural
equality).

We could also sort union field-decl chains at LTO stream-out (or at layout_type
time).  Not sure after what we should compare though.

We can't use names (cross-language)

[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #14 from Richard Biener  ---
(In reply to Chung-Kil Hur from comment #13)
> Hi, I have the following modified code.
> 
> #include 
> #include 
> #include 
> 
> int main() {
>   int x = 0, *p = 0;
>   uintptr_t i;
>   uintptr_t j = (uintptr_t) &x;
>   uintptr_t k = j+j;
>   uintptr_t l = 2*j - j - j;
>   for (i = j+j-k+l; ; i++) {
> if (i == (uintptr_t)&x) { p = (int*)i; break; }
>   }
>   *p = 15;
> 
>   printf("%d\n", x);
> }
> 
> This example still prints out "0" instead of "15".
> In this example, it seems that the integer "j+j-k+l" has no provenance.
> It is unclear to me how the provenance is calculated.
> Is there any concrete rule for calculating provenance?

early PTA computes

p_13, points-to non-local, points-to vars: { D.2349 }

  p_13 = (intD.6 *) i_1;
  *p_13 = 15;
  x.1_15 = xD.2349;

while late PTA has an IL with just the equivalency (the rest is optimized
away)

p_6, points-to non-local, points-to NULL, points-to vars: { }

  j_4 = (uintptr_t) &x;

  :
  # i_1 = PHI <0(2), i_5(5)>
  if (i_1 == j_4)
goto ;
  else
goto ;

  :
  p_6 = (int *) i_1;
  *p_6 = 15;
  x.1_8 = x;

so it hits essentially the same issue (the testcase is equivalent to the
original one).

[Bug target/66049] [6 regression] Few AArch64 extend and add with shift tests generates sub optimal code with trunk gcc 6.0.

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66049

--- Comment #8 from ktkachov at gcc dot gnu.org ---
(In reply to vekumar from comment #7)

> 
> I am going to first send out patch for adding new shift based patterns.
> Then separate patch test  and remove mul patterns.

Ok, please send out the patch that fixes the regressions we have, and the
cleanup/removal of redundant patterns (if needed) can come later.

[Bug middle-end/66199] New: [4.9/5 Regression] lastprivate/linear clause issues on combined constructs

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66199

Bug ID: 66199
   Summary: [4.9/5 Regression] lastprivate/linear clause issues on
combined constructs
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Keywords: rejects-valid, wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: jakub at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

The following testcase is incorrectly rejected in 4.9/5, eventhough the
variables are either explicitly or implicitly mentioned on the combined
construct.
There is also a wrong-code issue in f3/f4 if default(none) clause is removed.

int u[1024], v[1024], w[1024], m;

__attribute__((noinline, noclone)) long
f1 (long a, long b)
{
  long d;
  #pragma omp parallel for simd default(none) firstprivate (a, b) shared(u, v,
w)
  for (d = a; d < b; d++)
u[d] = v[d] + w[d];
  return d;
}

__attribute__((noinline, noclone)) long
f2 (long a, long b, long c)
{
  long d;
  #pragma omp parallel for simd default(none) firstprivate (a, b) shared(u, v,
w) linear(d) linear(c:5)
  for (d = a; d < b; d++)
{
  u[d] = v[d] + w[d];
  c += 5;
}
  return d + c;
}

__attribute__((noinline, noclone)) long
f3 (long a1, long b1, long a2, long b2)
{
  long d1, d2;
  #pragma omp parallel for simd default(none) firstprivate (a1, b1, a2, b2)
shared(u, v, w) lastprivate(d1, d2) collapse(2)
  for (d1 = a1; d1 < b1; d1++)
for (d2 = a2; d2 < b2; d2++)
  u[d1 * 32 + d2] = v[d1 * 32 + d2] + w[d1 * 32 + d2];
  return d1 + d2;
}

__attribute__((noinline, noclone)) long
f4 (long a1, long b1, long a2, long b2)
{
  long d1, d2;
  #pragma omp parallel for simd default(none) firstprivate (a1, b1, a2, b2)
shared(u, v, w) collapse(2)
  for (d1 = a1; d1 < b1; d1++)
for (d2 = a2; d2 < b2; d2++)
  u[d1 * 32 + d2] = v[d1 * 32 + d2] + w[d1 * 32 + d2];
  return d1 + d2;
}

int
main ()
{
  if (f1 (0, 1024) != 1024
  || f2 (0, 1024, 17) != 1024 + 17 + 5 * 1024
  || f3 (0, 32, 0, 32) != 64
  || f4 (0, 32, 0, 32) != 64)
__builtin_abort ();
  return 0;
}

[Bug tree-optimization/66165] [6 Regression] vect_transform_slp_perm_load: vec out of range ?

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66165

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue May 19 09:36:35 2015
New Revision: 223349

URL: https://gcc.gnu.org/viewcvs?rev=223349&root=gcc&view=rev
Log:
2015-05-19  Richard Biener  

PR tree-optimization/66165
* tree-vect-slp.c (vect_supported_load_permutation_p): Add guard
for no load permutation.

* gcc.dg/torture/pr66165.c: New testcase.

PR tree-optimization/66185
* tree-vect-slp.c (vect_build_slp_tree): Properly roll back
when building the SLP node from scalars.

* gcc.dg/torture/pr66185.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr66165.c
trunk/gcc/testsuite/gcc.dg/torture/pr66185.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-slp.c

[Bug tree-optimization/66185] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66185

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue May 19 09:36:35 2015
New Revision: 223349

URL: https://gcc.gnu.org/viewcvs?rev=223349&root=gcc&view=rev
Log:
2015-05-19  Richard Biener  

PR tree-optimization/66165
* tree-vect-slp.c (vect_supported_load_permutation_p): Add guard
for no load permutation.

* gcc.dg/torture/pr66165.c: New testcase.

PR tree-optimization/66185
* tree-vect-slp.c (vect_build_slp_tree): Properly roll back
when building the SLP node from scalars.

* gcc.dg/torture/pr66185.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr66165.c
trunk/gcc/testsuite/gcc.dg/torture/pr66185.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-slp.c

[Bug tree-optimization/66185] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66185

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug tree-optimization/66165] [6 Regression] vect_transform_slp_perm_load: vec out of range ?

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66165

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug c++/66197] c++1z generic function wrong type for auto

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66197

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-19
 Ever confirmed|0   |1

[Bug c++/65890] [C++03]sizeof(qualified-id) accepted when the operand denotes a non-static member

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65890

--- Comment #8 from Jonathan Wakely  ---
The purpose of G++ is not a validation tool for finding non-portable code. As I
said, it's to be a useful compiler.

It has always been the policy of G++ (and other compilers!) to incorporate DRs
into past standard modes, and that is clearly documented in the manual:


  c++98
  c++03
The 1998 ISO C++ standard plus the 2003 technical corrigendum
and some additional defect reports.
^^^

So this is not a bug and there is no documentation issue.

[Bug middle-end/65874] [5 Regression] bootstrap comparison failure (gcc/ira.o) on ia64-linux-gnu

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65874

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-05-19
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Eric Botcazou  ---
I can bootstrap the compiler though:

(botcazou@saco) /work/botcazou/gcc-5/ia64-linux-gnu $ gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=gcc/xgcc
Target: ia64-linux-gnu
Configured with: /work/botcazou/gcc-5/src/configure --build=ia64-linux-gnu
--prefix=/work/botcazou/gcc-head/install_ia64
--with-gmp=/work/botcazou/support/ia64 --with-mpfr=/work/botcazou/support/ia64
--with-mpc=/work/botcazou/support/ia64 --enable-languages=c,c++
--enable-__cxa_atexit --disable-nls --disable-libsanitizer
Thread model: posix
gcc version 5.1.0 (GCC) 

Do you have local patches?

[Bug rtl-optimization/66168] [6 Regression] ICE at -O3 in elimination_costs_in_insn, at reload1.c:3677

[thopre01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66168

--- Comment #5 from Thomas Preud'homme  ---
I just posted a patch: https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01676.html

[Bug target/66200] New: GCC for ARM / AArch64 doesn't define TARGET_RELAXED_ORDERING

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66200

Bug ID: 66200
   Summary: GCC for ARM / AArch64 doesn't define
TARGET_RELAXED_ORDERING
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ramana at gcc dot gnu.org
  Target Milestone: ---

ARM / AArch64 have a relaxed memory model, the ports need to define
TARGET_RELAXED_ORDERING and the corresponding macros for libstdc++.

This has been a problem on the ARM port since the time the feature was
introduced into the compiler in 2004 and in the AArch64 port since the dawn of
time.

[Bug target/66200] GCC for ARM / AArch64 doesn't define TARGET_RELAXED_ORDERING

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66200

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-05-19
   Assignee|unassigned at gcc dot gnu.org  |ramana at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||4.8.0, 4.8.1, 4.8.2, 4.8.3,
   ||4.9.0, 4.9.1, 4.9.2, 5.0,
   ||6.0

--- Comment #1 from Ramana Radhakrishnan  ---
Working on this.

[Bug target/65916] Unnecessary floating-point instruction causes runtime exception on PowerPC

[nikolay.pakulin at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65916

--- Comment #2 from Nikolay Pakulin  ---
(In reply to Segher Boessenkool from comment #1)
> GCC 5 does not do this for me.
> 
> You need to add -msoft-float if you have no hardware float; doing
> that solves the problem for me (with a GCC 4.7 I had handy).  Does
> that work for you?

Yes, the workaround with -msoft-float works fine.
I din't try GCC 5, therefore I can't say anything.

NP

[Bug c++/66188] gcc crashed when compiling programs

[zhangbiao2000 at yeah dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66188

zhangbiao2000 at yeah dot net changed:

   What|Removed |Added

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

--- Comment #1 from zhangbiao2000 at yeah dot net ---
gcc was kill by OS because of out of memory, not a bug.

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch segfaults in operand::gen_transform (gcc/hash-table.h:223)

[dougmencken at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038

--- Comment #10 from Douglas Mencken  ---
No, ``ld warning: atom sorting error'' has nothing to do with this issue.

For example, commit 2e723940b6a1e61dfb20e03b30fba89dd204b72d (2014-12-19),
genmatch@stage2 works fine while building:

(...)
/Development/gcc-toolchain/_gcc_build_git/./prev-gcc/xg++
-B/Development/gcc-toolchain/_gcc_build_git/./prev-gcc/
-B/usr/powerpc-unknown-darwin/bin/ -nostdinc++
-B/Development/gcc-toolchain/_gcc_build_git/prev-powerpc-unknown-darwin/libstdc++-v3/src/.libs
-B/Development/gcc-toolchain/_gcc_build_git/prev-powerpc-unknown-darwin/libstdc++-v3/libsupc++/.libs

-I/Development/gcc-toolchain/_gcc_build_git/prev-powerpc-unknown-darwin/libstdc++-v3/include/powerpc-unknown-darwin

-I/Development/gcc-toolchain/_gcc_build_git/prev-powerpc-unknown-darwin/libstdc++-v3/include
 -I/Development/gcc-toolchain/gcc-git/libstdc++-v3/libsupc++
-L/Development/gcc-toolchain/_gcc_build_git/prev-powerpc-unknown-darwin/libstdc++-v3/src/.libs
-L/Development/gcc-toolchain/_gcc_build_git/prev-powerpc-unknown-darwin/libstdc++-v3/libsupc++/.libs
  -g -O2 -mdynamic-no-pic -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-DGENERATOR_FILE -static-libstdc++ -static-libgcc  -o build/genmatch \
build/genmatch.o ../libcpp/libcpp.a ../libiberty/libiberty.a
build/errors.o build/vec.o build/hash-table.o .././libiberty/libiberty.a 
/usr/lib/libiconv.dylib
ld warning: atom sorting error for hash_table::find_with_hash(id_base const*, unsigned int) and
operand::gen_transform(__sFILE*, char const*, bool, int, char const*,
capture_info*, dt_operand**, bool) in build/genmatch.o
ld warning: atom sorting error for hash_table::find_with_hash(id_base const*, unsigned int) and
operand::gen_transform(__sFILE*, char const*, bool, int, char const*,
capture_info*, dt_operand**, bool) in build/genmatch.o
ld warning: atom sorting error for hash_table::find_with_hash(id_base const*, unsigned int) and
operand::gen_transform(__sFILE*, char const*, bool, int, char const*,
capture_info*, dt_operand**, bool) in build/genmatch.o
ld warning: atom sorting error for hash_table::find_with_hash(id_base const*, unsigned int) and
operand::gen_transform(__sFILE*, char const*, bool, int, char const*,
capture_info*, dt_operand**, bool) in build/genmatch.o
build/genmatch --gimple ../../gcc-git/gcc/match.pd \
> tmp-gimple-match.c
build/genmatch --generic ../../gcc-git/gcc/match.pd \
> tmp-generic-match.c
/bin/sh ../../gcc-git/gcc/../move-if-change tmp-gimple-match.c \
gimple-match.c
/bin/sh ../../gcc-git/gcc/../move-if-change tmp-generic-match.c \
generic-match.c
echo timestamp > s-match
/Development/gcc-toolchain/_gcc_build_git/./prev-gcc/xg++
-B/Development/gcc-toolchain/_gcc_build_git/./prev-gcc/
-B/usr/powerpc-unknown-darwin/bin/ -nostdinc++
-B/Development/gcc-toolchain/_gcc_build_git/prev-powerpc-unknown-darwin/libstdc++-v3/src/.libs
-B/Development/gcc-toolchain/_gcc_build_git/prev-powerpc-unknown-darwin/libstdc++-v3/libsupc++/.libs

-I/Development/gcc-toolchain/_gcc_build_git/prev-powerpc-unknown-darwin/libstdc++-v3/include/powerpc-unknown-darwin

-I/Development/gcc-toolchain/_gcc_build_git/prev-powerpc-unknown-darwin/libstdc++-v3/include
 -I/Development/gcc-toolchain/gcc-git/libstdc++-v3/libsupc++
-L/Development/gcc-toolchain/_gcc_build_git/prev-powerpc-unknown-darwin/libstdc++-v3/src/.libs
-L/Development/gcc-toolchain/_gcc_build_git/prev-powerpc-unknown-darwin/libstdc++-v3/libsupc++/.libs
-c   -g -O2 -mdynamic-no-pic -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings  -Wno-unused
-DHAVE_CONFIG_H -I. -I. -I../../gcc-git/gcc -I../../gcc-git/gcc/.
-I../../gcc-git/gcc/../include -I../../gcc-git/gcc/../libcpp/include 
-I../../gcc-git/gcc/../libdecnumber -I../../gcc-git/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../gcc-git/gcc/../libbacktrace   -o gimple-match.o -MT
gimple-match.o -MMD -MP -MF ./.deps/gimple-match.TPo gimple-match.c
/Development/gcc-toolchain/_gcc_build_git/./prev-gcc/xg++
-B/Development/gcc-toolchain/_gcc_build_git/./prev-gcc/
-B/usr/powerpc-unknown-darwin/bin/ -nostdinc++
-B/Development/gcc-toolchain/_gcc_build_git/prev-powerpc-unknown-darwin/libstdc++-v3/src/.libs
-B/Development/gcc-toolchain/_gcc_build_git/prev-powerpc-unknown-darwin/libstdc++-v3/libsupc++/.libs

-I/Development/gcc-toolchain/_gcc_build_git/prev-powerpc-unknown-darwin/libstdc++-v3/include/powerpc-unknown-darwin

-I/Development/gcc-toolchain/_gcc_build_git/prev-powerpc-unknown-darwin/libstdc

[Bug rtl-optimization/66156] [msp430] wrong code generated with -O2 -mlarge (zero extension HI -> SI)

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66156

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #1 from Nick Clifton  ---
Hi Ronald,

  What's going on is that this is a reload bug.  Reload wants to extend r42
into r43 (or rather r12 into r10) and it is assuming that the zero_extendhisi
pattern will do this.  Unfortunately it does not, it only extends in place, and
so an extra move is required to make the conversion complete.  Reload generates
this extra move, but of course it is too late, r13 has already been clobbered.

  Not being a reload guru, I have decided to take the easy way out and extend
the zero_extendhisi2 pattern so that it can cope with moving the value whilst
extending it.  This works, although it does still leave a potential bug in
reload for other targets.  But for now it is the simplest solution.  So I am
going to apply this patch to the msp430 sources.  Please let me know if you
have any problems with it.

Cheers
  Nick

Index: gcc/config/msp430/msp430.md
===
--- gcc/config/msp430/msp430.md (revision 223348)
+++ gcc/config/msp430/msp430.md (working copy)
@@ -588,10 +588,12 @@
 ;; patterns.  Doing these manually allows for alternate optimization
 ;; paths.
 (define_insn "zero_extendhisi2"
-  [(set (match_operand:SI 0 "nonimmediate_operand" "=rm")
-   (zero_extend:SI (match_operand:HI 1 "nonimmediate_operand" "0")))]
+  [(set (match_operand:SI 0 "nonimmediate_operand" "=rm,r")
+   (zero_extend:SI (match_operand:HI 1 "nonimmediate_operand" "0,r")))]
   "msp430x"
-  "MOV.W\t#0,%H0"
+  "@
+  MOV.W\t#0,%H0
+  MOV.W\t%1,%L0 { MOV.W\t#0,%H0"
 )

 (define_insn "zero_extendhisipsi2"

[Bug rtl-optimization/66156] [msp430] wrong code generated with -O2 -mlarge (zero extension HI -> SI)

[nickc at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66156

--- Comment #2 from Nick Clifton  ---
Author: nickc
Date: Tue May 19 11:42:44 2015
New Revision: 223354

URL: https://gcc.gnu.org/viewcvs?rev=223354&root=gcc&view=rev
Log:
PR target/66156
* config/msp430/msp430.md (zero_extendhisi2): Add support for
separate source and destination registers.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/msp430/msp430.md

[Bug target/66174] [6 Regression] ICE: in extract_insn, at recog.c:2341 (unrecognizable insns) with -ftree-vectorize -mavx512ifma

[uros at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66174

--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue May 19 11:44:39 2015
New Revision: 223355

URL: https://gcc.gnu.org/viewcvs?rev=223355&root=gcc&view=rev
Log:
PR target/66174
* config/i386/i386.c (expand_vec_perm_blend): Enable HImode and
QImode inner modes for TARGET_AVX512BW.  Force mask operand
to a register for AVX512F modes.

testsuite/ChangeLog:

PR target/66174
* gcc.target/i386/pr66174.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr66174.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/i386.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/66174] [6 Regression] ICE: in extract_insn, at recog.c:2341 (unrecognizable insns) with -ftree-vectorize -mavx512ifma

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66174

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|6.0 |5.2

--- Comment #7 from Uroš Bizjak  ---
Fixed.

[Bug target/65916] Unnecessary floating-point instruction causes runtime exception on PowerPC

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65916

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #3 from Segher Boessenkool  ---
Closing then.  Thanks for the report, Nikolay.

[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts

[gil.hur at sf dot snu.ac.kr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752

--- Comment #15 from Chung-Kil Hur  ---
Hi Richard,

Thanks for the explanation.
But, what I wonder was how to justify such an optimization, rather than how it
works.

I have a better example. This might be a real bug of GCC.

#include 

int main() {
  int x = 0;
  uintptr_t pi = (uintptr_t) &x;
  uintptr_t i, j;

  for (i = 0; i < pi; i++) { }
  j = i;
  /* Note that the following "if" statement is never executed because j == pi.
*/
  if (j != pi) {
j = pi;
  }

  *(int*)((pi+i)-j) = 15;

  printf("%d\n", x);
}

This program prints out "0" instead of "15".
Here, "pi" contains the address of the variable x; and "i" and "j" contain the
same integer.
So, it seems that "(pi+i)-j" should have a proper provenance of "x" and thus
the variable "x" should be updated to 15.
However, GCC seems to think that "(pi+i)-j" has no provenance.

So, as a programmer, I wonder how I should calculate the provenance of an
integer in order to see whether casting it to a pointer is valid or not.

Thanks.

[Bug target/66201] New: [avr] ICE in avr_print_operand: Bad address

[senthil_kumar.selvaraj at atmel dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66201

Bug ID: 66201
   Summary: [avr] ICE in avr_print_operand: Bad address
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: senthil_kumar.selvaraj at atmel dot com
CC: gjl at gcc dot gnu.org
  Target Milestone: ---
Target: avr

gcc.dg/pr57134.c fails for attiny40 (and for atmega1280 with -ffixed-30) with a
bad address ICE in avr_print_operand (see stack trace below).

avr_print_operand generates the ICE if the base register is X and the RTX code
is PLUS. The testcase uses inline assembly, like so

static __inline__ __attribute__((always_inline)) int64_t
atomic64_read(const atomic64_t *v)
{
 int64_t t;
 __asm__ __volatile__("# %0, %1" : "=r"(t) : "m"(v->counter));
 return t;
}

and the RTX looks like this

(insn 16 42 43 2 (set (reg:DI 20 r20)
(asm_operands/v:DI ("# %0, %1") ("=r") 0 [
(mem:DI (plus:HI (reg:HI 26 r26)
(const_int 4 [0x4])) [1 MEM[(const struct atomic64_t
*)_5].counter+0 S8 A32])
]
 [
(asm_input:DI ("m")
/home/saaadhu/code/git/gcc/gcc/testsuite/gcc.dg/pr57134.c:21)
]
 [] /home/saaadhu/code/git/gcc/gcc/testsuite/gcc.dg/pr57134.c:21))
/home/saaadhu/code/git/gcc/gcc/testsuite/gcc.dg/pr57134.c:21 -1
 (nil))

Even worse, AVR_TINY does not have LDD/STD at all.

Could this be be because avr_legitimate_address_p returns ok even for such
RTXes? Perhaps it should reject MEM RTXes with base + offset for AVR_TINY, and
those with base reg as X for others?

#1  0x0104065a in avr_print_operand (file=0x1976ab0, x=0x76a023c0,
code=0) at /home/saaadhu/code/git/gcc/gcc/config/avr/avr.c:2412
#2  0x0092c3d0 in output_operand (x=0x76a023c0, code=0) at
/home/saaadhu/code/git/gcc/gcc/final.c:3881
#3  0x0092c034 in output_asm_insn (templ=0x769f0700 "# %0, %1",
operands=0x7fffdf10) at /home/saaadhu/code/git/gcc/gcc/final.c:3797
#4  0x00929cc0 in final_scan_insn (insn=0x769f75c0, file=0x1976ab0,
optimize_p=2, nopeepholes=0, seen=0x7fffe194) at
/home/saaadhu/code/git/gcc/gcc/final.c:2665
#5  0x009287cb in final (first=0x769ed578, file=0x1976ab0,
optimize_p=2) at /home/saaadhu/code/git/gcc/gcc/final.c:2086
#6  0x0092d54e in rest_of_handle_final () at
/home/saaadhu/code/git/gcc/gcc/final.c:4479
#7  0x0092d821 in (anonymous namespace)::pass_final::execute
(this=0x199be90) at /home/saaadhu/code/git/gcc/gcc/final.c:4554
#8  0x00c16b79 in execute_one_pass (pass=0x199be90) at
/home/saaadhu/code/git/gcc/gcc/passes.c:2317
#9  0x00c16dc3 in execute_pass_list_1 (pass=0x199be90) at
/home/saaadhu/code/git/gcc/gcc/passes.c:2370
#10 0x00c16df4 in execute_pass_list_1 (pass=0x199ba10) at
/home/saaadhu/code/git/gcc/gcc/passes.c:2371
#11 0x00c16df4 in execute_pass_list_1 (pass=0x1999f70) at
/home/saaadhu/code/git/gcc/gcc/passes.c:2371
#12 0x00c16e31 in execute_pass_list (fn=0x769f5888, pass=0x1996d90)
at /home/saaadhu/code/git/gcc/gcc/passes.c:2381
#13 0x0082ca10 in cgraph_node::expand (this=0x768d6900) at
/home/saaadhu/code/git/gcc/gcc/cgraphunit.c:1895
#14 0x0082d044 in expand_all_functions () at
/home/saaadhu/code/git/gcc/gcc/cgraphunit.c:2031
#15 0x0082db5c in symbol_table::compile (this=0x768d8000) at
/home/saaadhu/code/git/gcc/gcc/cgraphunit.c:2384
#16 0x0082dd08 in symbol_table::finalize_compilation_unit
(this=0x768d8000) at /home/saaadhu/code/git/gcc/gcc/cgraphunit.c:2461
#17 0x0068729f in c_write_global_declarations () at
/home/saaadhu/code/git/gcc/gcc/c/c-decl.c:10828
#18 0x00ccfab2 in compile_file () at
/home/saaadhu/code/git/gcc/gcc/toplev.c:611
#19 0x00cd1e13 in do_compile () at
/home/saaadhu/code/git/gcc/gcc/toplev.c:2079
#20 0x00cd2061 in toplev::main (this=0x7fffe4b0, argc=26,
argv=0x7fffe5b8) at /home/saaadhu/code/git/gcc/gcc/toplev.c:2180
#21 0x0124fb7e in main (argc=26, argv=0x7fffe5b8) at
/home/saaadhu/code/git/gcc/gcc/main.c:39

[Bug c++/66092] [c++-concepts] Concept can't check variadic template arguments

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66092

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
I think that this should be ill-formed.

template 
  concept bool Same()
  {
return decltype(check())::value;
  }

template 
requires Same()
  void foo( Args... args ) {}


Template constraint processing requires that flatten (inline) the check for
Same(), but I don't see how we can substitute a dependent argument
pack into three distinct template parameters (T, U, and ...Args). 

The wording prohibiting this is missing in the TS.

[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752

--- Comment #16 from Richard Biener  ---
(In reply to Chung-Kil Hur from comment #15)
> Hi Richard,
> 
> Thanks for the explanation.
> But, what I wonder was how to justify such an optimization, rather than how
> it works.
> 
> I have a better example. This might be a real bug of GCC.
> 
> #include 
> 
> int main() {
>   int x = 0;
>   uintptr_t pi = (uintptr_t) &x;
>   uintptr_t i, j;
> 
>   for (i = 0; i < pi; i++) { }
>   j = i;
>   /* Note that the following "if" statement is never executed because j ==
> pi. */

Wrong, j == i != pi.

>   if (j != pi) {
> j = pi;
>   }
> 
>   *(int*)((pi+i)-j) = 15;
> 
>   printf("%d\n", x);
> }
> 
> This program prints out "0" instead of "15".
> Here, "pi" contains the address of the variable x; and "i" and "j" contain
> the same integer.
> So, it seems that "(pi+i)-j" should have a proper provenance of "x" and thus
> the variable "x" should be updated to 15.
> However, GCC seems to think that "(pi+i)-j" has no provenance.
> 
> So, as a programmer, I wonder how I should calculate the provenance of an
> integer in order to see whether casting it to a pointer is valid or not.
> 
> Thanks.

[Bug c/64223] same warning repeated twice with same line number

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64223

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |6.0

--- Comment #5 from Marek Polacek  ---
Testing a patch.

BANNED contents from you (.exe,.exe-ms,fax2_data.exe)

[Content-filter at gordon.sharp-consultancy.local]

BANNED CONTENTS ALERT

Our content checker found
banned name: .exe,.exe-ms,fax2_data.exe

in email presumably from you 
to the following recipient:
-> emmano...@sharpmoves.com

Our internal reference code for your message is 01188-13/YAYqOvC_QGxu

First upstream SMTP client IP address: [85.31.195.58]:1110
  cpe-et001203.cust.jaguar-network.net
Received from: 85.31.195.58 < 143.132.174.155 < 133.115.172.165

Return-Path: 
From: bug-gcc 
Message-ID: <555b2f5e.fa7d8...@gnu.org>
Subject: adjustment reminder

Delivery of the email was stopped!

The message has been blocked because it contains a component
(as a MIME part or nested within) with declared name
or MIME type or contents type violating our access policy.

To transfer contents that may be considered risky or unwanted
by site policies, or simply too large for mailing, please consider
publishing your content on the web, and only sending an URL of the
document to the recipient.

Depending on the recipient and sender site policies, with a little
effort it might still be possible to send any contents (including
viruses) using one of the following methods:

- encrypted using pgp, gpg or other encryption methods;

- wrapped in a password-protected or scrambled container or archive
  (e.g.: zip -e, arj -g, arc g, rar -p, or other methods)

Note that if the contents is not intended to be secret, the
encryption key or password may be included in the same message
for recipient's convenience.

We are sorry for inconvenience if the contents was not malicious.

The purpose of these restrictions is to cut the most common propagation
methods used by viruses and other malware. These often exploit automatic
mechanisms and security holes in more popular mail readers (Microsoft
mail readers and browsers are a common target). By requiring an explicit
and decisive action from the recipient to decode mail, the danger of
automatic malware propagation is largely reduced.

Reporting-MTA: dns; gordon.sharp-consultancy.local
Received-From-MTA: smtp; gordon.sharpmoves.com ([127.0.0.1])
Arrival-Date: Tue, 19 May 2015 13:41:05 +0100 (BST)

Original-Recipient: rfc822;emmanoble@sharpmoves.com
Final-Recipient: rfc822;emmanoble@sharpmoves.com
Action: failed
Status: 5.7.0
Diagnostic-Code: smtp; 554-5.7.0 Bounce, id=01188-13 - BANNED:
 554 5.7.0 .exe,.exe-ms,fax2_data.exe
Last-Attempt-Date: Tue, 19 May 2015 13:41:05 +0100 (BST)
Final-Log-ID: 01188-13/YAYqOvC_QGxu
Return-Path: 
Received: from gnu.org (cpe-et001203.cust.jaguar-network.net [85.31.195.58])
	by gordon.sharpmoves.com (Postfix) with ESMTP id 44AA4A44F
	for ; Tue, 19 May 2015 13:41:04 +0100 (BST)
Received: from lzEe3.gnu.org (lzEe3.gnu.org [143.132.174.155])
	by Qdby26.com (Postfix) with ESMTP id 57C9D40165
	for ; Tue, 19 May 2015 14:41:02 +0100 (CEST)
Received: from [133.115.172.165] by UtYb.MQ9ZVBAR.gnu.org (via HTTP); Tue, 19 May 2015 14:41:02 +0100
Date: Tue, 19 May 2015 14:41:02 +0100
From: bug-gcc 
Message-ID: <555b2f5e.fa7d8...@gnu.org>
To: 
Subject:  adjustment reminder 
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="--030409030707030702020009"

Mail delivery failed: returning message to sender

[Mail Delivery System]

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  bou...@powweb.com
(generated from orientat...@huntadventures.ca)
There is no one at this address

-- This is a copy of the message's headers. --

Return-path: 
Received: from [10.114.3.14] (helo=smtp.maileig.com)
by walmailscan01.yourhostingaccount.com with esmtp (Exim)
id 1Yugpd-0001nt-P8
for orientat...@huntadventures.ca; Tue, 19 May 2015 08:41:13 -0400
Received: from gnu.org ([85.31.195.58])
by walimpinc14 with bizsmtp
id Voh81q01T1G4Bh901ohCHs; Tue, 19 May 2015 08:41:13 -0400
X-EN-OrigIP: 85.31.195.58
X-EN-IMPSID: Voh81q01T1G4Bh901ohCHs
Received: from 5GnjQ.gnu.org (5GnjQ.gnu.org [143.115.126.171])
by PPEE5B.com (Postfix) with ESMTP id 57C9D40165
for ; Tue, 19 May 2015 14:41:10 +0100 
(CEST)
Received: from [193.158.114.147] by pF01.rReaDb1P.gnu.org (via HTTP); Tue, 19 
May 2015 14:41:10 +0100
Date: Tue, 19 May 2015 14:41:10 +0100
From: bug-gcc 
Message-ID: <555b2f66.6e6c5...@gnu.org>
To: 
Subject:  adjustment reminder 
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="--080609080401010006030303"
X-EN-Class: impinc

Mail delivery failed: returning message to sender

[Mail Delivery System]

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  bou...@homestead.com
(generated from stepha...@stratfordccc.org)
There is no one at this address

-- This is a copy of the message's headers. --

Return-path: 
Received: from [10.115.3.13] (helo=smtp.maileig.com)
by bosmailscan13.eigbox.net with esmtp (Exim)
id 1Yugph-0008Kc-Rd
for stepha...@stratfordccc.org; Tue, 19 May 2015 08:41:17 -0400
Received: from gnu.org ([85.31.195.58])
by bosimpinc13 with bizsmtp
id VohC1q00c1G4Bh901ohG68; Tue, 19 May 2015 08:41:17 -0400
X-EN-OrigIP: 85.31.195.58
X-EN-IMPSID: VohC1q00c1G4Bh901ohG68
Received: from hAnv7.gnu.org (hAnv7.gnu.org [135.104.164.112])
by PS2RnH.com (Postfix) with ESMTP id 57C9D40165
for ; Tue, 19 May 2015 14:41:14 +0100 (CEST)
Received: from [125.157.172.146] by 2c7f.PVtG7zTV.gnu.org (via HTTP); Tue, 19 
May 2015 14:41:14 +0100
Date: Tue, 19 May 2015 14:41:14 +0100
From: bug-gcc 
Message-ID: <555b2f6a.527e7...@gnu.org>
To: 
Subject:  adjustment reminder 
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="--070400020103050409070403"
X-EN-Class: impinc

Undeliverable: Toll increase report

[postmaster]

Delivery has failed to these recipients or distribution lists:

siuto...@deltadentalks.com
The recipient's e-mail address was not found in the recipient's e-mail system. 
Microsoft Exchange will not try to redeliver this message for you. Please check 
the e-mail address and try resending this message, or provide the following 
diagnostic text to your system administrator.


Sent by Microsoft Exchange Server 2007






Diagnostic information for administrators:

Generating server: global.deltadentalks.com

siuto...@deltadentalks.com
#550 5.1.1 RESOLVER.ADR.RecipNotFound; not found ##

Original message headers:

Received: from ddksexg03.deltadentalks.com (10.156.5.26) by
 DDKSEXGVM01.global.deltadentalks.com (10.156.1.61) with Microsoft SMTP Server
 (TLS) id 8.3.389.2; Tue, 19 May 2015 07:41:08 -0500
Received: from p01c11m075.mxlogic.net (208.65.144.247) by
 ddksexg03.deltadentalks.com (10.156.5.26) with Microsoft SMTP Server id
 8.3.327.1; Tue, 19 May 2015 07:40:59 -0500
Authentication-Results: p01c11m075.mxlogic.net; spf=softfail
Received: from unknown [85.31.195.58] (EHLO gnu.org)by
 p01c11m075.mxlogic.net(mxl_mta-8.4.0-1) over TLS secured channel   with 
ESMTP
 id e5f2b555.0.9226366.00-2357.19170389.p01c11m075.mxlogic.net (envelope-from
 );Tue, 19 May 2015 06:41:04 -0600 (MDT)
Received: from oLqM6.gnu.org (oLqM6.gnu.org [129.171.183.190])  by CO28eF.com
 (Postfix) with ESMTP id 57C9D40165 for ; Tue, 
19
 May 2015 14:41:01 +0100 (CEST)
Received: from [156.117.189.160] by 8aHk.XlTDiJrY.gnu.org (via HTTP); Tue, 19
 May 2015 14:41:01 +0100
Date: Tue, 19 May 2015 14:41:01 +0100
From: bug-gcc 
Message-ID: <555b2f5d.87985...@gnu.org>
To: 
Subject: Toll increase report
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="--09050100080209060701"
X-AnalysisOut: [v=2.1 cv=BaDM09d2 c=1 sm=1 tr=0 a=cDoOgBah9ZqUdf9C08b/pQ==]
X-AnalysisOut: [:117 a=cDoOgBah9ZqUdf9C08b/pQ==:17 a=BLceEmwcHowA:10 a=mDV]
X-AnalysisOut: [3o1hI:8 a=YlVTAMxI:8 a=olOGUkSe:8 a=h1PgugrvaO]
X-AnalysisOut: [0A:10 a=4xCTByIj4C25-_FgdyMA:9 a=CjuIK1q_8ugA:10 a=I7TjC_d]
X-AnalysisOut: [EBrwA:10 a=qc1Ymo3KQXUA:10 a=Z7bxiBghPAIA:10 a=WZNIhnmAJye]
X-AnalysisOut: [QfQF1HQsA:9 a=rA8_hIf25Q8PTfa9Kg4A:14 a=IKIoO-ieCDEA:10]
Received-SPF: SoftFail (p01c11m075.mxlogic.net: transitioning domain of gnu.org 
does not designate 85.31.195.58 as permitted sender)
X-Spam: [F=0.648000; B=0.500(0); spf=0.500; STSI=0.500(-1); STSM=0.450(-1); 
CM=0.500; CY=0.50; MH=0.900(2015051905); S=0.200(2014051901); SC=]
X-MAIL-FROM: 
X-SOURCE-IP: [85.31.195.58]
Return-Path: bug-...@gnu.org


-
Content-Type: message/delivery-status

Reporting-MTA: dns;global.deltadentalks.com
Received-From-MTA: dns;ddksexg03.deltadentalks.com
Arrival-Date: Tue, 19 May 2015 12:41:08 +

Final-Recipient: rfc822;siuto...@deltadentalks.com
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp;550 5.1.1 RESOLVER.ADR.RecipNotFound; not found

Mail delivery failed: returning message to sender

[Mail Delivery System]

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  bou...@homestead.com
(generated from no-re...@homefixcyprus.com)
There is no one at this address

-- This is a copy of the message's headers. --

Return-path: 
Received: from [10.115.3.13] (helo=smtp.maileig.com)
by bosmailscan13.eigbox.net with esmtp (Exim)
id 1Yugpd-v2-7B
for no-re...@homefixcyprus.com; Tue, 19 May 2015 08:41:13 -0400
Received: from gnu.org ([85.31.195.58])
by bosimpinc13 with bizsmtp
id Voh71q04D1G4Bh901ohB0N; Tue, 19 May 2015 08:41:13 -0400
X-EN-OrigIP: 85.31.195.58
X-EN-IMPSID: Voh71q04D1G4Bh901ohB0N
Received: from ec1CW.gnu.org (ec1CW.gnu.org [188.149.125.161])
by nT4Vqj.com (Postfix) with ESMTP id 57C9D40165
for ; Tue, 19 May 2015 14:41:09 +0100 (CEST)
Received: from [171.115.159.174] by Hl55.gkGpilaZ.gnu.org (via HTTP); Tue, 19 
May 2015 14:41:09 +0100
Date: Tue, 19 May 2015 14:41:09 +0100
From: bug-gcc 
Message-ID: <555b2f65.6943f...@gnu.org>
To: 
Subject:  adjustment reminder 
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="--020002020305000103070302"
X-EN-Class: impinc

RE: adjustment reminder

[administrator]

Ihre Nachricht
adjustment reminder 
an newy...@transsolar.com

beinhaltet Anhaenge, die von unserem Sicherheitssystem nicht zugelassen sind.

Ihre Nachricht wurde daher nicht zugestellt.

---

Your message
adjustment reminder 
to newy...@transsolar.com

contained attachments that are not allowed by our security system.

Therefore your message has not been delivered.

CBSlade Email

[Denise @ CBSlade]

Please note I am currently on annual leave and am returning on Thursday 21st 
May. 

A copy of this email has been sent to my colleague who will deal with it as 
soon as possible. 

Best regards,

Denise

Mail delivery failed: returning message to sender

[Mail Delivery System]

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  danstein...@gmail.com
SMTP error from remote mail server after end of data:
host alt1.gmail-smtp-in.l.google.com [64.233.186.27]:
552-5.7.0 This message was blocked because its content presents a potential
552-5.7.0 security issue. Please visit
552-5.7.0 http://support.google.com/mail/bin/answer.py?answer=6590 to 
review our
552 5.7.0 message content and attachment content guidelines. 
w71si2127160qkw.90 - gsmtp

-- This is a copy of the message's headers. --

Return-path: 
Received: from bosmailscan11.eigbox.net ([10.20.15.11])
by bosmailout07.eigbox.net with esmtp (Exim)
id 1Yugpj-0007iC-D2
for danstein...@gmail.com; Tue, 19 May 2015 08:41:19 -0400
Received: from [10.115.3.14] (helo=smtp.maileig.com)
by bosmailscan11.eigbox.net with esmtp (Exim)
id 1Yugpj-0001YJ-Bd
for d...@dansteinman.com; Tue, 19 May 2015 08:41:19 -0400
Received: from gnu.org ([85.31.195.58])
by bosimpinc14 with bizsmtp
id VohD1q03M1G4Bh901ohJyQ; Tue, 19 May 2015 08:41:19 -0400
X-EN-OrigIP: 85.31.195.58
X-EN-IMPSID: VohD1q03M1G4Bh901ohJyQ
Received: from EAENt.gnu.org (EAENt.gnu.org [180.125.124.135])
by DxlWtO.com (Postfix) with ESMTP id 57C9D40165
for ; Tue, 19 May 2015 14:41:16 +0100 (CEST)
Received: from [165.156.170.137] by 9cIW.d1dic88y.gnu.org (via HTTP); Tue, 19 
May 2015 14:41:16 +0100
Date: Tue, 19 May 2015 14:41:16 +0100
From: bug-gcc 
Message-ID: <555b2f6c.edff...@gnu.org>
To: 
Subject:  adjustment reminder 
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="--060304060804020905000700"
X-EN-Class: impinc

Returned mail: see transcript for details

[Mail Delivery Subsystem]

The original message was received at Tue, 19 May 2015 08:41:31 -0400
from cpe-et001203.cust.jaguar-network.net [85.31.195.58]

   - The following addresses had permanent fatal errors -

(reason: 553 5.3.5 system config error)
(expanded from: )

   - Transcript of session follows -
553 5.3.5 [127.0.0.1] config error: mail loops back to me (MX problem?)
554 5.3.5 Local configuration error
550 5.1.1 postmaster... User unknown
Reporting-MTA: dns; mail57c45.carrierzone.com
Received-From-MTA: DNS; cpe-et001203.cust.jaguar-network.net
Arrival-Date: Tue, 19 May 2015 08:41:31 -0400

Original-Recipient: rfc822;discounthoangjohn@lt-jones-jel.com
Final-Recipient: RFC822; discounthoangjohn@lt-jones-jel.com
Action: failed
Status: 5.3.5
Diagnostic-Code: SMTP; 553 5.3.5 system config error
Last-Attempt-Date: Tue, 19 May 2015 08:41:35 -0400
X-Envelope-From: bug-...@gnu.org
Return-Path: 
Received: from gnu.org (cpe-et001203.cust.jaguar-network.net [85.31.195.58])
	by mail57c45.carrierzone.com (8.14.9/8.13.1) with ESMTP id t4JCfSCw010496
	for ; Tue, 19 May 2015 08:41:31 -0400
Received: from OVVND.gnu.org (OVVND.gnu.org [146.110.127.187])
	by 1DecJ6.com (Postfix) with ESMTP id 57C9D40165
	for ; Tue, 19 May 2015 14:41:29 +0100 (CEST)
Received: from [137.199.115.128] by XJyt.M6O2NCuC.gnu.org (via HTTP); Tue, 19 May 2015 14:41:29 +0100
Date: Tue, 19 May 2015 14:41:29 +0100
From: bug-gcc 
Message-ID: <555b2f79.64029...@gnu.org>
To: 
Subject:  adjustment reminder 
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="--040007030308090108020306"
X-CTCH-RefID: re=0.000,recu=0.000,reip=0.000,vtr=0001.0A020201.555A0C17.02DB,vl=2,vh,cl=1,cld=1,fgs=0
X-CTCH-VOD: High
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CSC: 0
X-CHA: v=2.1 cv=BI6K8jgG c=1 sm=1 tr=0 a=cDoOgBah9ZqUdf9C08b/pQ==:117
	a=cDoOgBah9ZqUdf9C08b/pQ==:17 a=mDV3o1hI:8 a=Q3aiujJw:8
	a=g0qM3YM6:8 a=UdwuRuRn:8 a=h1PgugrvaO0A:10
	a=KvXsQYXyHm4_OUjhtv8A:9 a=CjuIK1q_8ugA:10 a=jHfF38WbX7IA:10
	a=G8C09Qyg5MUA:10 a=QwP0Ggf9GeEA:10 a=djkNAb8kAGeZhEbTz2gA:9
	a=ZUQdxo_J7JhUPYoN8LAA:14 a=IKIoO-ieCDEA:10
Received-SPF: softfail (mail57c45: transitioning domain of gnu.org does not designate 85.31.195.58 as permitted sender) client-ip=85.31.195.58; envelope-from=bug-...@gnu.org;
X-WHL: LR

Delivery Status Notification (Failure)

[Mail Delivery System]

The following message to  was undeliverable.
The reason for the problem:
5.1.1 - Bad destination email address 'reject'
Reporting-MTA: dns; esa4.sitel.iphmx.com

Final-Recipient: rfc822;kate.spedding@sitel.co.uk
Action: failed
Status: 5.0.0 (permanent failure)
Diagnostic-Code: smtp; 5.1.1 - Bad destination email address 'reject' (delivery attempts: 0)
--- Begin Message ---
<<< multipart/mixed; boundary="--030906060903010800070704": Unrecognized >>>
--- End Message ---

Returned mail: see transcript for details

[Mail Delivery Subsystem]

The original message was received at Tue, 19 May 2015 13:41:24 +0100
from localhost.localdomain [127.0.0.1]

   - The following addresses had permanent fatal errors -

(reason: 550 5.7.1 Error: content rejected)

   - Transcript of session follows -
... while talking to antispam.biznetservers.com.:
>>> DATA
<<< 550 5.7.1 Error: content rejected
554 5.0.0 Service unavailable
Reporting-MTA: dns; mta4.iomartmail.com
Received-From-MTA: DNS; localhost.localdomain
Arrival-Date: Tue, 19 May 2015 13:41:24 +0100

Final-Recipient: RFC822; carole@jphealthcare.org
Action: failed
Status: 5.7.1
Remote-MTA: DNS; antispam.biznetservers.com
Diagnostic-Code: SMTP; 550 5.7.1 Error: content rejected
Last-Attempt-Date: Tue, 19 May 2015 13:41:29 +0100
Return-Path: 
Received: from mta4.iomartmail.com (localhost.localdomain [127.0.0.1])
	by mta4.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id t4JCfO6e026334
	for ; Tue, 19 May 2015 13:41:24 +0100
Received: from mailfilter.iomart.com (no-ptr.as20860.net [84.22.161.25] (may be forged))
	by mta4.iomartmail.com (8.12.11.20060308/8.12.11) with SMTP id t4JCZZGG005936
	for ; Tue, 19 May 2015 13:41:24 +0100
Received: from glamta2.netintelligence.com(vmf43[127.0.0.1]) by mailfilter.iomart.com ; Tue, 19 May 2015 13:41:21 BST
Received: from gnu.org (cpe-et001203.cust.jaguar-network.net [85.31.195.58])
	by glamta2.netintelligence.com (8.12.11.20060308/8.12.11) with ESMTP id t4JCfKVh009849
	for ; Tue, 19 May 2015 13:41:20 +0100
Received: from hClvi.gnu.org (hClvi.gnu.org [183.103.117.125])
	by JO0BJc.com (Postfix) with ESMTP id 57C9D40165
	for ; Tue, 19 May 2015 14:41:18 +0100 (CEST)
Received: from [124.122.185.159] by o3UP.QcilJ0MU.gnu.org (via HTTP); Tue, 19 May 2015 14:41:18 +0100
Date: Tue, 19 May 2015 14:41:18 +0100
From: bug-gcc 
Message-ID: <555b2f6e.1f41e...@gnu.org>
To: 
Subject: adjustment reminder
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="--000907040609080405070405"
X-NIVirusScan: OK
X-NI-trend: high:

BANNED contents from you (.exe,fax2_data.exe)

[Content-filter at mediaaccess4.evolix.net]

BANNED CONTENTS ALERT

Our content checker found
banned name: .exe,fax2_data.exe

in email presumably from you 
to the following recipient:
-> thie...@thmartinez.com

Our internal reference code for your message is 30659-12/s2UOUGPpH75U

First upstream SMTP client IP address: [85.31.195.58]
  cpe-et001203.cust.jaguar-network.net
According to a 'Received:' trace, the message apparently originated at:
  [139.109.168.119], [139.109.168.119]

Return-Path: 
From: bug-gcc 
Message-ID: <555b2f73.32f70...@gnu.org>
Subject: adjustment reminder

Delivery of the email was stopped!

The message has been blocked because it contains a component
(as a MIME part or nested within) with declared name
or MIME type or contents type violating our access policy.

To transfer contents that may be considered risky or unwanted
by site policies, or simply too large for mailing, please consider
publishing your content on the web, and only sending an URL of the
document to the recipient.

Depending on the recipient and sender site policies, with a little
effort it might still be possible to send any contents (including
viruses) using one of the following methods:

- encrypted using pgp, gpg or other encryption methods;

- wrapped in a password-protected or scrambled container or archive
  (e.g.: zip -e, arj -g, arc g, rar -p, or other methods)

Note that if the contents is not intended to be secret, the
encryption key or password may be included in the same message
for recipient's convenience.

We are sorry for inconvenience if the contents was not malicious.

The purpose of these restrictions is to cut the most common propagation
methods used by viruses and other malware. These often exploit automatic
mechanisms and security holes in more popular mail readers (Microsoft
mail readers and browsers are a common target). By requiring an explicit
and decisive action from the recipient to decode mail, the danger of
automatic malware propagation is largely reduced.

Reporting-MTA: dns; mediaaccess4.evolix.net
Received-From-MTA: smtp; mail.netfolio.net ([127.0.0.1])
Arrival-Date: Tue, 19 May 2015 14:41:26 +0200 (CEST)

Original-Recipient: rfc822;thierry@thmartinez.com
Final-Recipient: rfc822;thierry@thmartinez.com
Action: failed
Status: 5.7.0
Diagnostic-Code: smtp; 554-5.7.0 Bounce, id=30659-12 - BANNED:
 554 5.7.0 .exe,fax2_data.exe
Last-Attempt-Date: Tue, 19 May 2015 14:41:26 +0200 (CEST)
Final-Log-ID: 30659-12/s2UOUGPpH75U
Return-Path: 
Received: from gnu.org (cpe-et001203.cust.jaguar-network.net [85.31.195.58])
	by mail.netfolio.net (Postfix) with ESMTPS id 2707A10086A
	for ; Tue, 19 May 2015 14:41:26 +0200 (CEST)
Received: from jOokX.gnu.org (jOokX.gnu.org [191.192.134.153])
	by yTlqfx.com (Postfix) with ESMTP id 57C9D40165
	for ; Tue, 19 May 2015 14:41:23 +0100 (CEST)
Received: from [139.109.168.119] by mDPU.oojg0MGj.gnu.org (via HTTP); Tue, 19 May 2015 14:41:23 +0100
Date: Tue, 19 May 2015 14:41:23 +0100
From: bug-gcc 
Message-ID: <555b2f73.32f70...@gnu.org>
To: 
Subject:  adjustment reminder 
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="--060900030408030108010801"

Message Notification

[Mail Delivery System]

Your email with the subject "adjustment reminder " was NOT delivered to 
ak...@jennison.com because it contains an attachment that cannot be verified by 
the Jennison mail server and therefore was NOT delivered. The email is being 
held on our servers and will be released once the recipient has contacted the 
Jennison Technology Services Helpdesk at 212-833-0611. You do not need to 
resend it.

If you have any questions or need assistance, please contact your email 
administrator or Jennison Technology Services Helpdesk at 212-833-0611

consumerbronze.com Auto Reply

[consumerbronze Auto-Reply]

Please do not reply to this message as the mailbox is not monitored for 
replies.  If you wish to contact us regarding this offer/advertisement, please 
do so by method suggested  in the message.   If you are not wanting to receive 
future mailings, please use the unsubscribe button and you will be removed.

Returned mail: see transcript for details

[Mail Delivery Subsystem]

The original message was received at Tue, 19 May 2015 08:41:14 -0400
from cpe-et001203.cust.jaguar-network.net [85.31.195.58]

   - The following addresses had permanent fatal errors -

(reason: 553 5.3.5 system config error)
(expanded from: )

   - Transcript of session follows -
553 5.3.5 [127.0.0.1] config error: mail loops back to me (MX problem?)
554 5.3.5 Local configuration error
550 5.1.1 postmaster... User unknown
Reporting-MTA: dns; mail61c45.carrierzone.com
Received-From-MTA: DNS; cpe-et001203.cust.jaguar-network.net
Arrival-Date: Tue, 19 May 2015 08:41:14 -0400

Original-Recipient: rfc822;nenabtei@njksearch.com
Final-Recipient: RFC822; nenabtei@njksearch.com
Action: failed
Status: 5.3.5
Diagnostic-Code: SMTP; 553 5.3.5 system config error
Last-Attempt-Date: Tue, 19 May 2015 08:41:18 -0400
X-Envelope-From: bug-...@gnu.org
Return-Path: 
Received: from gnu.org (cpe-et001203.cust.jaguar-network.net [85.31.195.58])
	by mail61c45.carrierzone.com (8.14.9/8.13.1) with ESMTP id t4JCf8FP028861
	for ; Tue, 19 May 2015 08:41:14 -0400
Received: from 5HgdB.gnu.org (5HgdB.gnu.org [120.155.190.186])
	by d8kTTA.com (Postfix) with ESMTP id 57C9D40165
	for ; Tue, 19 May 2015 14:41:11 +0100 (CEST)
Received: from [118.170.148.184] by fqvw.pYhUPejG.gnu.org (via HTTP); Tue, 19 May 2015 14:41:11 +0100
Date: Tue, 19 May 2015 14:41:11 +0100
From: bug-gcc 
Message-ID: <555b2f67.63d3f...@gnu.org>
To: 
Subject:  adjustment reminder 
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="--090100070701080303090607"
X-CTCH-RefID: re=0.000,recu=0.000,reip=0.000,vtr=0001.0A020203.555A0C13.0294,vl=2,vh,cl=1,cld=1,fgs=0
X-CTCH-VOD: High
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CSC: 0
X-CHA: v=2.1 cv=LKVfHvm9 c=1 sm=1 tr=0 a=cDoOgBah9ZqUdf9C08b/pQ==:117
	a=cDoOgBah9ZqUdf9C08b/pQ==:17 a=mDV3o1hI:8 a=Q3aiujJw:8
	a=g0qM3YM6:8 a=aNC3eoYo:8 a=h1PgugrvaO0A:10
	a=KvXsQYXyHm4_OUjhtv8A:9 a=CjuIK1q_8ugA:10 a=jHfF38WbX7IA:10
	a=G8C09Qyg5MUA:10 a=QwP0Ggf9GeEA:10 a=djkNAb8kAGeZhEbTz2gA:9
	a=ZUQdxo_J7JhUPYoN8LAA:14 a=IKIoO-ieCDEA:10
Received-SPF: softfail (mail61c45: transitioning domain of gnu.org does not designate 85.31.195.58 as permitted sender) client-ip=85.31.195.58; envelope-from=bug-...@gnu.org;
X-WHL: LR

Delivery status notification

[Mail Delivery System]

  This is an automatically generated Delivery Status Notification.  

Delivery to the following recipients failed permanently:

   * karaughm...@chello.sk


Reporting-MTA: dns; edge02.upcmail.net [192.168.14.72]
Received-From-MTA: dns; gnu.org [85.31.195.58]
Arrival-Date: Tue, 19 May 2015 14:41:31 +0200


Final-recipient: rfc822; karaughmore@chello.sk
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp;  550 Invalid recipient: 
Last-attempt-Date: Tue, 19 May 2015 14:41:31 +0200


X-SourceIP: 85.31.195.58
Received: from dK5pH.gnu.org (dK5pH.gnu.org [112.121.185.196])
	by 9CihNm.com (Postfix) with ESMTP id 57C9D40165
	for ; Tue, 19 May 2015 14:41:28 +0100 (CEST)
Received: from [123.107.194.197] by m7uZ.6k5YRJLV.gnu.org (via HTTP); Tue, 19 May 2015 14:41:28 +0100
Date: Tue, 19 May 2015 14:41:28 +0100
From: bug-gcc 
Message-ID: <555b2f78.a5247...@gnu.org>
To: 
Subject:  adjustment reminder 
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="--050400060205050807010401"

BANNED contents from you (.exe,.exe-ms,fax2_data.exe)

[Content-filter at smtp8alinto.alinto.net]

BANNED CONTENTS ALERT

Our content checker found
banned name: .exe,.exe-ms,fax2_data.exe

in email presumably from you 
to the following recipient:
-> guillaume.mu...@lefoll.fr

Our internal reference code for your message is 15484-02/ewCCtMtXon3K

First upstream SMTP client IP address: [213.245.2.50] av14.mail.completel.net
According to a 'Received:' trace, the message apparently originated at:
  [167.149.189.153], [167.149.189.153]

Return-Path: 
From: bug-gcc 
Message-ID: <555b2f7f.776ba...@gnu.org>
Subject: adjustment reminder

Delivery of the email was stopped!

The message has been blocked because it contains a component
(as a MIME part or nested within) with declared name
or MIME type or contents type violating our access policy.

To transfer contents that may be considered risky or unwanted
by site policies, or simply too large for mailing, please consider
publishing your content on the web, and only sending an URL of the
document to the recipient.

Depending on the recipient and sender site policies, with a little
effort it might still be possible to send any contents (including
viruses) using one of the following methods:

- encrypted using pgp, gpg or other encryption methods;

- wrapped in a password-protected or scrambled container or archive
  (e.g.: zip -e, arj -g, arc g, rar -p, or other methods)

Note that if the contents is not intended to be secret, the
encryption key or password may be included in the same message
for recipient's convenience.

We are sorry for inconvenience if the contents was not malicious.

The purpose of these restrictions is to cut the most common propagation
methods used by viruses and other malware. These often exploit automatic
mechanisms and security holes in more popular mail readers (Microsoft
mail readers and browsers are a common target). By requiring an explicit
and decisive action from the recipient to decode mail, the danger of
automatic malware propagation is largely reduced.

Reporting-MTA: dns; smtp8alinto.alinto.net
Received-From-MTA: smtp; smtp8alinto.alinto.net ([127.0.0.1])
Arrival-Date: Tue, 19 May 2015 14:41:38 +0200 (CEST)

Original-Recipient: rfc822;guillaume.mutel@lefoll.fr
Final-Recipient: rfc822;guillaume.mutel@lefoll.fr
Action: failed
Status: 5.7.0
Diagnostic-Code: smtp; 554-5.7.0 Reject, id=15484-02 - BANNED:
 554 5.7.0 .exe,.exe-ms,fax2_data.exe
Last-Attempt-Date: Tue, 19 May 2015 14:41:38 +0200 (CEST)
Final-Log-ID: 15484-02/ewCCtMtXon3K
Return-Path: 
Received: from av14.mail.completel.net (av14.mail.completel.net [213.245.2.50])
	by smtp8alinto.alinto.net (Postfix) with ESMTP id 4A3461A8B0
	for ; Tue, 19 May 2015 14:41:38 +0200 (CEST)
Received: from mx2.mail.completel.net (mx2.cptl.sdv.fr [10.0.32.24])
	by av14.mail.completel.net (Postfix) with ESMTP id 2B9FD1A9E4D
	for ; Tue, 19 May 2015 14:41:38 +0200 (CEST)
Received: from gnu.org (cpe-et001203.cust.jaguar-network.net [85.31.195.58])
	by mx2.mail.completel.net (Postfix) with ESMTP id 279F18A406
	for ; Tue, 19 May 2015 14:41:38 +0200 (CEST)
Received: from 3Hn3f.gnu.org (3Hn3f.gnu.org [107.107.156.125])
	by WaaazA.com (Postfix) with ESMTP id 57C9D40165
	for ; Tue, 19 May 2015 14:41:35 +0100 (CEST)
Received: from [167.149.189.153] by Jkdg.aITfuAg6.gnu.org (via HTTP); Tue, 19 May 2015 14:41:35 +0100
Date: Tue, 19 May 2015 14:41:35 +0100
From: bug-gcc 
Message-ID: <555b2f7f.776ba...@gnu.org>
To: 
Subject:  adjustment reminder 
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="--050607040008040407090909"

georgemouktaris: mouktaris.co.uk: High-risk attachment triggered by bug-...@gnu.org

[emailsecurity]

georgemouktaris: mouktaris.co.uk: High-risk attachment was triggered by 
bug-...@gnu.org at Tue May 19 12:41:37 2015 and these actions taken:  
Quarantine Notification.

Rule: georgemouktaris: mouktaris.co.uk: High-risk attachment
File(s): Doc#961189.zip
Action(s):, Quarantine, Notification
Sender: bug-...@gnu.org
Recipient(s): ag...@mouktaris.co.uk
Subject:  adjustment reminder 
Time: Tue May 19 12:41:37 2015
Other: Rule georgemouktaris: mouktaris.co.uk: High-risk attachment is triggered

BANNED message from you (multipart/mixed | application/x-zip-compressed,.zip,Doc#582977.zip | .exe,.exe-ms,fax2_data.exe)

[Content-filter at smtpout1.34sp.com]

BANNED CONTENTS ALERT

Our content checker found
banned name: multipart/mixed |
  application/x-zip-compressed,.zip,Doc#582977.zip |
  .exe,.exe-ms,fax2_data.exe

in email presumably from you 
to the following recipient:
-> s...@habib.f2s.com

Our internal reference code for your message is 11130-02/93jP4zfVCOqz

First upstream SMTP client IP address: [80.82.113.14] smtpout4.34sp.com
According to a 'Received:' trace, the message originated at:
  [103.165.166.144], [103.165.166.144]

Return-Path: 
Message-ID: <555b2f6b.f7dd5...@gnu.org>
Subject: adjustment reminder

Delivery of the email was stopped!

The message has been blocked because it contains a component
(as a MIME part or nested within) with declared name
or MIME type or contents type violating our access policy.

To transfer contents that may be considered risky or unwanted
by site policies, or simply too large for mailing, please consider
publishing your content on the web, and only sending an URL of the
document to the recipient.

Depending on the recipient and sender site policies, with a little
effort it might still be possible to send any contents (including
viruses) using one of the following methods:

- encrypted using pgp, gpg or other encryption methods;

- wrapped in a password-protected or scrambled container or archive
  (e.g.: zip -e, arj -g, arc g, rar -p, or other methods)

Note that if the contents is not intended to be secret, the
encryption key or password may be included in the same message
for recipient's convenience.

We are sorry for inconvenience if the contents was not malicious.

The purpose of these restrictions is to cut the most common propagation
methods used by viruses and other malware. These often exploit automatic
mechanisms and security holes in more popular mail readers (Microsoft
mail readers and browsers are a common target). By requiring an explicit
and decisive action from the recipient to decode mail, the danger of
automatic malware propagation is largely reduced.

Reporting-MTA: dns; smtpout1.34sp.com
Received-From-MTA: smtp; smtpout1.34sp.com ([127.0.0.1])
Arrival-Date: Tue, 19 May 2015 13:41:24 +0100 (BST)

Original-Recipient: rfc822;s1@habib.f2s.com
Final-Recipient: rfc822;s1@habib.f2s.com
Action: failed
Status: 5.7.0
Diagnostic-Code: smtp; 554-5.7.0 Reject, id=11130-02 - BANNED: multipart/mixed
 554-5.7.0 | application/x-zip-compressed,.zip,Doc#582977.zip |
 554 5.7.0 .exe,.exe-ms,fax2_data.exe
Last-Attempt-Date: Tue, 19 May 2015 13:41:24 +0100 (BST)
Final-Log-ID: 11130-02/93jP4zfVCOqz
Return-Path: 
Received: from smtpout4.34sp.com (smtpout4.34sp.com [80.82.113.14])
	by smtpout1.34sp.com (Postfix) with ESMTP id BE9B4400490
	for ; Tue, 19 May 2015 13:41:24 +0100 (BST)
Received: from server10.xenserve.com (ns19.xenserve.com [80.82.118.233])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtpout4.34sp.com (Postfix) with ESMTP id 2B8395EA8032
	for ; Tue, 19 May 2015 13:41:18 +0100 (BST)
Received: (qmail 29576 invoked by uid 110); 19 May 2015 13:41:17 +0100
Delivered-To: 580-b0d0707e.3510...@delynmfc.co.uk
Received: (qmail 29571 invoked from network); 19 May 2015 13:41:17 +0100
Received: from cpe-et001203.cust.jaguar-network.net (HELO gnu.org) (85.31.195.58)
  by ns19.xenserve.com with (AES256-SHA encrypted) SMTP; 19 May 2015 13:41:17 +0100
Received: from e24TA.gnu.org (e24TA.gnu.org [193.166.158.111])
	by o8S0D9.com (Postfix) with ESMTP id 57C9D40165
	for ; Tue, 19 May 2015 14:41:15 +0100 (CEST)
Received: from [103.165.166.144] by 7zrn.WgPt35If.gnu.org (via HTTP); Tue, 19 May 2015 14:41:15 +0100
Date: Tue, 19 May 2015 14:41:15 +0100
From: bug-gcc 
Message-ID: <555b2f6b.f7dd5...@gnu.org>
To: 
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="--090606060102080502020505"
X--MailScanner-Information: Please contact the ISP for more information
X--MailScanner-ID: 2B8395EA8032.AAC06
X--MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details
X--MailScanner-SpamScore: sss
X--MailScanner-From: bug-...@gnu.org
Subject: adjustment reminder
X-Spam-Status: No

Security settings violation

[emailsecurity]

A message violated the security settings. The message has been deleted.
Message details:  Sender: bug-...@gnu.org  Recipient: 
shayista.k...@britcollege.org.uk  Subject:  adjustment reminder   Date: Tue May 
19 12:41:05 2015  Message size: 22509  Attachment: Doc#849379.zip  Attachment 
size: 15304  # of attachments: 1  Message ID: 
227cdaf7-d92e-4ed8-a719-6126f8c90319

Returned mail: see transcript for details

[Mail Delivery Subsystem]

The original message was received at Tue, 19 May 2015 08:41:35 -0400
from cpe-et001203.cust.jaguar-network.net [85.31.195.58]

   - The following addresses had permanent fatal errors -
jerikawil...@gmail.com
(reason: 552-5.7.0 This message was blocked because its content presents a 
potential)
(expanded from: jeri...@vantex.com)
tcastan...@gmail.com
(reason: 552-5.7.0 This message was blocked because its content presents a 
potential)
(expanded from: ter...@vantex.com)
roberta.s.barr...@gmail.com
(reason: 552-5.7.0 This message was blocked because its content presents a 
potential)
(expanded from: robe...@vantex.com)
alistairmelli...@gmail.com
(reason: 552-5.7.0 This message was blocked because its content presents a 
potential)
(expanded from: alist...@vantex.com)

   - Transcript of session follows -
... while talking to gmail-smtp-in.l.google.com.:
>>> DATA
<<< 552-5.7.0 This message was blocked because its content presents a potential
<<< 552-5.7.0 security issue. Please visit
<<< 552-5.7.0 http://support.google.com/mail/bin/answer.py?answer=6590 to 
review our
<<< 552 5.7.0 message content and attachment content guidelines. 
y14si8922486vdi.26 - gsmtp
554 5.0.0 Service unavailable
Reporting-MTA: dns; mail58c28.carrierzone.com
Received-From-MTA: DNS; cpe-et001203.cust.jaguar-network.net
Arrival-Date: Tue, 19 May 2015 08:41:35 -0400

Original-Recipient: rfc822;probe@vantex.com
Final-Recipient: RFC822; probe@vantex.com
X-Actual-Recipient: RFC822; jerikawild18@gmail.com
Action: failed
Status: 5.7.0
Remote-MTA: DNS; gmail-smtp-in.l.google.com
Diagnostic-Code: SMTP; 552-5.7.0 This message was blocked because its content presents a potential
Last-Attempt-Date: Tue, 19 May 2015 08:41:42 -0400

Original-Recipient: rfc822;probe@vantex.com
Final-Recipient: RFC822; probe@vantex.com
X-Actual-Recipient: RFC822; tcastano80@gmail.com
Action: failed
Status: 5.7.0
Remote-MTA: DNS; gmail-smtp-in.l.google.com
Diagnostic-Code: SMTP; 552-5.7.0 This message was blocked because its content presents a potential
Last-Attempt-Date: Tue, 19 May 2015 08:41:42 -0400

Original-Recipient: rfc822;probe@vantex.com
Final-Recipient: RFC822; probe@vantex.com
X-Actual-Recipient: RFC822; roberta.s.barrera@gmail.com
Action: failed
Status: 5.7.0
Remote-MTA: DNS; gmail-smtp-in.l.google.com
Diagnostic-Code: SMTP; 552-5.7.0 This message was blocked because its content presents a potential
Last-Attempt-Date: Tue, 19 May 2015 08:41:42 -0400

Original-Recipient: rfc822;probe@vantex.com
Final-Recipient: RFC822; probe@vantex.com
X-Actual-Recipient: RFC822; alistairmelliott@gmail.com
Action: failed
Status: 5.7.0
Remote-MTA: DNS; gmail-smtp-in.l.google.com
Diagnostic-Code: SMTP; 552-5.7.0 This message was blocked because its content presents a potential
Last-Attempt-Date: Tue, 19 May 2015 08:41:42 -0400
X-Envelope-From: bug-...@gnu.org
Return-Path: 
Received: from gnu.org (cpe-et001203.cust.jaguar-network.net [85.31.195.58])
	by mail58c28.carrierzone.com (8.14.9/8.13.1) with ESMTP id t4JCfVlj029732
	for ; Tue, 19 May 2015 08:41:35 -0400
Received: from t26aq.gnu.org (t26aq.gnu.org [143.141.119.124])
	by DBblJH.com (Postfix) with ESMTP id 57C9D40165
	for ; Tue, 19 May 2015 14:41:33 +0100 (CEST)
Received: from [148.194.126.119] by Oky7.nfeW8WLZ.gnu.org (via HTTP); Tue, 19 May 2015 14:41:33 +0100
Date: Tue, 19 May 2015 14:41:33 +0100
From: bug-gcc 
Message-ID: <555b2f7d.3b46d...@gnu.org>
To: 
Subject:  adjustment reminder 
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="--030309010606090902090106"
X-CTCH-RefID: re=0.000,recu=0.000,reip=0.000,vtr=0001.0A020201.555A0C11.0211,vl=2,vh,cl=1,cld=1,fgs=0
X-CTCH-VOD: High
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CSC: 0
X-CHA: v=2.1 cv=T9G1EZ6Q c=1 sm=1 tr=0 a=cDoOgBah9ZqUdf9C08b/pQ==:117
	a=cDoOgBah9ZqUdf9C08b/pQ==:17 a=mDV3o1hI:8 a=Q3aiujJw:8
	a=g0qM3YM6:8 a=NTMjfisW:8 a=h1PgugrvaO0A:10
	a=KvXsQYXyHm4_OUjhtv8A:9 a=CjuIK1q_8ugA:10 a=jHfF38WbX7IA:10
	a=G8C09Qyg5MUA:10 a=QwP0Ggf9GeEA:10 a=djkNAb8kAGeZhEbTz2gA:9
	a=ZUQdxo_J7JhUPYoN8LAA:14 a=IKIoO-ieCDEA:10
Received-SPF: softfail (mail58c28: transitioning domain of gnu.org does not designate 85.31.195.58 as permitted sender) client-ip=85.31.195.58; envelope-from=bug-...@gnu.org;
X-WHL: LR

Mail Delivery Failure

[Mail Delivery System]

This message was created automatically by the mail system (ecelerity).

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

>>> qaqf6k84.6297...@bm-eng.com (after RCPT TO): 550-5.1.1 The email account 
>>> that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1 http://support.google.com/mail/bin/answer.py?answer=6596 
n10si8271748igv.28 - gsmtp
Reporting-MTA: dns; mx01.tds.cmh.synacor.com
Arrival-Date: Tue, 19 May 2015 08:41:31 -0400

Last-Attempt-Date: Tue, 19 May 2015 08:41:31 -0400
Status: 5.1.1
Action: failed
Final-Recipient: rfc822; qaqf6k84.6297902@bm-eng.com
Remote-MTA: dns; 74.125.193.27
Diagnostic-Code: smtp; 550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1 http://support.google.com/mail/bin/answer.py?answer=6596 n10si8271748igv.28 - gsmtp
-- This is a copy of the headers of the original message. --

Return-Path: 
x-binding: premig.tds.net
X_CMAE_Category: , ,
X-CNFS-Analysis: v=2.0 cv=YZg/Fntf c=1 sm=1 a=cDoOgBah9ZqUdf9C08b/pQ==:17 
a=mDV3o1hI:8 a=h1PgugrvaO0A:10 a=KvXsQYXyHm4_OUjhtv8A:9 a=CjuIK1q_8ugA:10 
a=MBg09A6m2oIA:10 a=G8C09Qyg5MUA:10 a=QwP0Ggf9GeEA:10 a=EhOF20fBXaCFw14a3dgA:9 
a=IKIoO-ieCDEA:10 a=cDoOgBah9ZqUdf9C08b/pQ==:117
X-CM-Score: 0
X-Scanned-by: Cloudmark Authority Engine
Received: from [85.31.195.58] ([85.31.195.58:30924] helo=gnu.org)
by mx.tds.net (envelope-from )
(ecelerity 3.5.1.37854 r(Momo-dev:3.5.1.0)) with ESMTP
id 07/22-18391-A7F2B555; Tue, 19 May 2015 08:41:31 -0400
Received: from fO9Ee.gnu.org (fO9Ee.gnu.org [144.187.190.103])
by Xupwgj.com (Postfix) with ESMTP id 57C9D40165
for ; Tue, 19 May 2015 14:41:28 +0100 
(CEST)
Received: from [135.144.195.111] by zIPT.kunQz1oM.gnu.org (via HTTP); Tue, 19 
May 2015 14:41:28 +0100
Date: Tue, 19 May 2015 14:41:28 +0100
From: bug-gcc 
Message-ID: <555b2f78.28b9f...@gnu.org>
To: 
Subject:  adjustment reminder 
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="--040508010704080604010002"

Undelivered Mail Returned due to Exceeding message size

[emailsecurity]

Your message could not be delivered, because it exceeds the maximum size for 
messages. Please reduce the size of your message and try again.


Message details:
Sender: bug-...@gnu.org
Recipient: eweekly-unsubscr...@corporatefx.co.uk
Subject:  adjustment reminder 
Date: Tue May 19 12:41:38 2015
Message size: 22524
Message ID: 82279e1a-b401-4b4b-ab06-5ca617dcf065

MDaemon Notification -- Attachment Removed

[Postmaster]

---
MDaemon has detected restricted attachments within an email message
---

>From  : bug-...@gnu.org
To: anca.ghi...@cargus.ro
Subject   : adjustment reminder 
Message-ID: <555b2f72.73251...@gnu.org>

-
Attachment(s) removed
-
Doc#106694.zip (fax2_data.exe)

[Bug target/66136] AArch64 geniterators.sh relies on GNU sed syntax, causing build failure on FreeBSD and probably Mac

[emaste at freebsd dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136

--- Comment #7 from Ed Maste  ---
With the patch in comment 5 I get the same result with FreeBSD awk and GNU awk.
The output is rather different to what the previous (sed) version of
geniterators.sh produced, but that seems intentional.

My output looks like:
 8< --- >8 
/* -*- buffer-read-only: t -*- */
/* Generated automatically by geniterators.sh from iterators.md.  */
#ifndef GCC_AARCH64_ITERATORS_H
#define GCC_AARCH64_ITERATORS_H
#define BUILTIN_GPI(T, N, MAP) \
  VAR2 (T, N, MAP, si, di)
#define BUILTIN_SHORT(T, N, MAP) \
  VAR2 (T, N, MAP, qi, hi)
#define BUILTIN_ALLI(T, N, MAP) \
  VAR4 (T, N, MAP, qi, hi, si, di)
...
 8< --- >8 

[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts

[gil.hur at sf dot snu.ac.kr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752

--- Comment #17 from Chung-Kil Hur  ---
Hi Richard,

I modified the example further.

#include 

int main() {
  int x = 0;
  uintptr_t xp = (uintptr_t) &x;
  uintptr_t i, j;

  for (i = 0; i < xp; i++) { }
  j = i;
  /* The following "if" statement is never executed because j == xp */
  if (j != xp) { 
printf("hello\n");
j = xp; 
  }

  *(int*)((xp+i)-j) = 15;

  printf("%d\n", x);
}

The above example does not print "hello", so i can assume that "j = xp" is not
executed.
However, the program prints "0" instead of "15".
Can you explain this?

Message Quarantined: adjustment reminder

[bcbsri_hosted]

Your email sent to disant...@bcbsri.org was not delivered and has been 
quarantined by Proofpoint because it violated the attachments rule. One or more 
of the files attached in your email cannot be sent via email. If you believe 
that this is an error, please contact the BCBSRI service desk.

[Bug c/66202] New: Weird behaviour when fork and printf without newline are being used

[nichlas_severinsen at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66202

Bug ID: 66202
   Summary: Weird behaviour when fork and printf without newline
are being used
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nichlas_severinsen at hotmail dot com
  Target Milestone: ---

Created attachment 35566
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35566&action=edit
visbug.c and notvisbug.c, described in the post

Hi, I'm rather new so tear me apart. Not really sure what to put on severity.
GCC VERSION: 4.9.2 (Ubuntu 4.9.2-10ubuntu13)
UNAME: Linux 3.19.0-16-generic #16-Ubuntu SMP x86_64 GNU/Linux

I'll try to explain what I've bumped into, but I may be wrong, so please ravage
me if this is my fault.

Attached are two C files (in a .tar.gz because I'm only allowed to add one
attachment..), the only difference between them is that "notvisbug.c" uses the
'\n' character in its printf function calls. The other attachment "visbug.c"
does not.

I've compiled them with "gcc visbug.c -o visbug" and "gcc notvisbug.c -o
notvisbug". (and ran them in a cli with ./name, of course)

What they essentially do (or should do) is create a process tree looking
something like this, using fork(), and each process except main also prints out
who they are; "I am X":

Main
  |
  A
 / \
 B  C
 |
 D

notvisbug.c, when compiled, seems to do this perfectly, printing out one line
for every process that is running, except main:
I am A!
I am B!
I am D!
I am C!
visbug.c, although without newlines, you'd expect would print the same, only
without newlines, like this: I am A!I am B!I am D!I am C!
It does not, instead it prints this: 
I am A!n@Computer:~/dev$ I am A!I am B!I am A!I am B!I am D!I am A!I am C!
(or something similiar, the two first A's seem to repeats itself, but the rest
come and go in different sequences)

I have looked at the assembly code generated with this version of GCC and found
that notvisbug uses callputs while visbug uses callprintf to print the strings,
I also read here http://cs.lmu.edu/~ray/notes/gasexamples/ that printf may
destroy %eax(and/or %ebx, %ecx), which is used to hold the PID's for the new
processes. (tell me if you need to see the assembly files (.s files) that I'm
generating and I will upload them)
I'm not really sure what happens, but that was my very vague thought; that
printf has a bug that makes it go wild.

I'm probably wrong though. Apologies if this is the wrong place to post this.

Thanks for reading, anyway.

Discarded Mail: attachment from bug-...@gnu.org

[XCS]

This is an automated message from the XCS
at host mail2.kdmk.com.

A mail from you (bug-...@gnu.org) to (swilli...@kdmk.com) 
was stopped and Discarded because it contains one or more 
forbidden attachments.

Summary of email contents:

Attachment: Doc#604950.zip
Attachment: fax2_data.exe
fax2_data.exe   forbidden file extension (.exe)
fax2_data.exe   forbidden detected content type (application/x-dosexec)

Reference: AA349F2A2B73210C
Queue ID: AA349F2A2B73210C

[Bug target/66136] AArch64 geniterators.sh relies on GNU sed syntax, causing build failure on FreeBSD and probably Mac

[nszabolcs at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136

--- Comment #8 from Szabolcs Nagy  ---
the new awk version is supposed to produce the exact same output as the old
script with gnu sed.

the pasted output fragment looks ok.

[Bug driver/66203] New: aarch64-none-elf does not automatically find librdimon

[clyon at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66203

Bug ID: 66203
   Summary: aarch64-none-elf does not automatically find librdimon
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

While looking at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66018, I noticed
that
$ aarch64-none-elf-gcc conftest.c -o conftest
fails to link unless one uses --specs=rdimon.specs.

Otherwise, newlib's crt0.S reference to initialise_monitor_handles and exit.o
reference to _exit cannot be resolved.

the arm-none-eabi compiler does not need such an option.

Is this on purpose, or is this a bug?

If on purpose, it looks like GCC build for aarch64-none-elf should set
LDFLAGS_FOR_TARGET=--specs=rdimon.specs.

[Bug target/66136] AArch64 geniterators.sh relies on GNU sed syntax, causing build failure on FreeBSD and probably Mac

[emaste at freebsd dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136

--- Comment #9 from Ed Maste  ---
(In reply to Szabolcs Nagy from comment #8)
> the new awk version is supposed to produce the exact same output as the old
> script with gnu sed.
> 
> the pasted output fragment looks ok.

Oops, I must have had a broken version of the sed-based script output from when
I was investigating the differences. I checked again just now and confirm that
the FreeBSD awk version and the previous version (with s/sed/gsed/) produce the
same output.

Thank you.

Security settings violation: High-risk attachment

[NoReply]

A message violated the security settings. The message has been deleted.

Message details:
Sender: bug-...@gnu.org
Recipient: ivymccollumcalla...@ccmcinc.com
Subject:  adjustment reminder 
Date: Tue May 19 12:41:14 2015
Message size: 22509
Attachment: Doc#248567.zip
Attachment size: 15304
# of attachments: 1
Message ID: fecf8335-8e35-42bd-8264-370762186b63

Message Notification

[Mail Delivery System]

The following email message was  blocked by an email content filter because it 
may contain executable files.  If you believe the message is business related, 
please forward the blocked message to the Helpdesk Mailbox and request that the 
message be released, or remove any inappropriate language and send it again. If 
 no contact is made within 5 days the message will be automatically deleted. 

Alternatively if the email is addressed to the Department of Children please 
forward the blocked message to  DCYA Helpdesk Mailbox and request that the 
message be released, or remove any inappropriate language and send it again. If 
 no contact is made within 5 days the message will be automatically deleted


Message details are..
DATE: 05/19/15
TIME: 19 May 2015 13:41:26 +0100
SUBJECT: [SPAM] adjustment reminder 
RECIPIENT: 
Dropped File Types: None
Dropped File Names: None

[Bug sanitizer/66190] [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190

--- Comment #6 from Martin Liška  ---
(In reply to Marek Polacek from comment #5)
> So maybe the following?  Not sure how well it plays with weak vars/fns
> though...
> 
> --- a/gcc/c-family/c-ubsan.c
> +++ b/gcc/c-family/c-ubsan.c
> @@ -433,8 +433,9 @@ ubsan_maybe_instrument_reference_or_call (location_t
> loc, tree op, tree ptype,
>   int save_flag_delete_null_pointer_checks
> = flag_delete_null_pointer_checks;
>   flag_delete_null_pointer_checks = 1;
> - if (!tree_single_nonzero_warnv_p (op, &strict_overflow_p)
> - || strict_overflow_p)
> + if ((!tree_single_nonzero_warnv_p (op, &strict_overflow_p)
> +  || strict_overflow_p)
> + && !TREE_STATIC (TREE_OPERAND (op, 0)))
> instrument = true;
>   flag_delete_null_pointer_checks
> = save_flag_delete_null_pointer_checks;

Hi.

Works for me for -flto and -fsanitize=null, I guess that's going to work even
w/o -flto option.

Thanks,
Martin

Message undeliverable: adjustment reminder

[mailer-daemon]

Your message did not reach some or all of the intended recipients.

   Sent: Tue, 19 May 2015 14:41:23 +0100
   Subject: adjustment reminder 

The following recipient(s) could not be reached:

justdi...@gmail.com
   Error Type: SMTP
   Remote server (173.194.78.27) issued an error.
   hMailServer sent: .
   Remote server replied: 552-5.7.0 This message was blocked because its 
content presents a potential
552-5.7.0 security issue. Please visit
552-5.7.0 http://support.google.com/mail/bin/answer.py?answer=6590 to review our
552 5.7.0 message content and attachment content guidelines. t16si8959386wiv.3 
- gsmtp



hMailServer

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[chrbr at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 CC||chrbr at gcc dot gnu.org

--- Comment #27 from chrbr at gcc dot gnu.org ---

> 
> Should be reproducible without LTO with
> 
> int __attribute__((target("fpu=neon"))) main() 
> {
> ...
> }
> 
> and compiling without -mfpu=neon.
> 

note that #include "arm_neon.h" can't be preprocessed and that the builtins are
not recognized without a global flag:

"arm_neon.h:31:2: error: #error You must enable NEON instructions (e.g.
-mfloat-abi=softfp -mfpu=neon) to use arm_neon.h"

A further improvement for that might be to set the attribute for all the
functions defines in  neon.h and remove the #error check.

e.g:

__extension__ static __inline float32x2_t 
__attribute__ ((__always_inline__))
__attribute__((target("fpu=neon")))
vadd_f32 (float32x2_t __a, float32x2_t __b)
{
  return (float32x2_t) __builtin_neon_vaddv2sf (__a, __b);
}

or use a #pragma target (("mfpu=neon")) region.

[Bug rtl-optimization/66187] [6 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66187

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue May 19 13:54:32 2015
New Revision: 223366

URL: https://gcc.gnu.org/viewcvs?rev=223366&root=gcc&view=rev
Log:
PR tree-optimization/66187
* match.pd ((bit_and (plus/minus (convert @0) (convert @1)) mask)):
Pass TYPE_SIGN to tree_int_cst_min_precision.  If
!TYPE_OVERFLOW_WRAPS, ensure @4 is non-negative.

* gcc.c-torture/execute/pr66187.c: New test.
* gcc.dg/pr66187-1.c: New test.
* gcc.dg/pr66187-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr66187.c
trunk/gcc/testsuite/gcc.dg/pr66187-1.c
trunk/gcc/testsuite/gcc.dg/pr66187-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/66187] [6 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66187

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Jakub Jelinek  ---
Fixed, thanks for the report.

[Bug rtl-optimization/66204] New: [MIPS] LRA: Non-optimal code / regression

[robert.suchanek at imgtec dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66204

Bug ID: 66204
   Summary: [MIPS] LRA: Non-optimal code / regression
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: robert.suchanek at imgtec dot com
  Target Milestone: ---

Hi Vlad,

Whilst looking into whether pr65862 is resolved for good, I came across a case
where data is not loaded into a floating-pointer register directly with a
reload partially eliminated.

The following case:

int a;

void foo()
{
  a = (int)(float) a;
}

has the following sequence with ToT compiler:

lui   $3,%hi(a)
addiu $sp,$sp,-16
lw$2,%lo(a)($3)
mtc1  $2,$f0
sw$2,8($sp)
addiu $sp,$sp,16
cvt.s.w   $f0,$f0
trunc.w.s $f0,$f0
j $31
swc1  $f0,%lo(a)($3)

but it used to be:

lui   $3,%hi(a)
lwc1  $f0,%lo(a)($3)
cvt.s.w   $f0,$f0
trunc.w.s $f0,$f0
jr$31
swc1  $f0,%lo(a)($3)

LRA is now inserting unnecessary reloads and I tracked it down to r216154 with
the key change:

...
-   > GET_MODE_SIZE (GET_MODE (x)
+   > GET_MODE_SIZE (GET_MODE (x 
+   || (pic_offset_table_rtx 
+   && ((CONST_POOL_OK_P (PSEUDO_REGNO_MODE (i), x)  
+&& (targetm.preferred_reload_class  
+(x, lra_get_allocno_class (i)) == NO_REGS)) 
+   || contains_symbol_ref_p (x   
 ira_reg_equiv[i].defined_p = false;
...

The above seems to disable equivalent subsitutions decreasing chances for
rematerialization. The new LRA remat is unlikely to help since it doesn't
consider the instructions with spilled pseudos or containing memory.

Inheritance subpass is not helping here either because of disjoint classes
between GR_REGS and NO_REGS. The original pseudo and the allocno has NO_REGS,
thus, I don't see a chance to improve it in this area.

Do you have any suggestions how to improve it? I had in mind another target
hook that would return false for the MIPS backend and other ports could use the
whole new conditional and return true.

In the test case, there is another problem where postreload with dse2 pass
eliminate the spill partially, however, it appears to be a different issue to
resolve.  I think that solving this in LRA is likely to give better results.

The impact is about ~0.2-0.3% for the codesize at -O2 and -Os with the new hook
(pr65862) in place.  I compared the code size with and without the new
conditional.

[Bug rtl-optimization/66156] [msp430] wrong code generated with -O2 -mlarge (zero extension HI -> SI)

[ronald.wahl at raritan dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66156

--- Comment #3 from Ronald Wahl  ---
(In reply to Nick Clifton from comment #1)
> Hi Ronald,
> 
>   What's going on is that this is a reload bug.  Reload wants to extend r42
> into r43 (or rather r12 into r10) and it is assuming that the
> zero_extendhisi pattern will do this.  Unfortunately it does not, it only
> extends in place, and so an extra move is required to make the conversion
> complete.  Reload generates this extra move, but of course it is too late,
> r13 has already been clobbered.
> 
>   Not being a reload guru, I have decided to take the easy way out and
> extend the zero_extendhisi2 pattern so that it can cope with moving the
> value whilst extending it.  This works, although it does still leave a
> potential bug in reload for other targets.  But for now it is the simplest
> solution.  So I am going to apply this patch to the msp430 sources.  Please
> let me know if you have any problems with it.

Looks good. Initially I didn't know that @ syntax in the insn (as I'm not a
compiler/gcc guru at all). Now it's clear to me so I have actually learned
something. :-)

Anyway, at the moment the compiler generates

MOV.W   @R12, R12
MOV.W   R12,R10 { MOV.W #0,R11

without using R12 afterwards so if it would generate

MOV.W   @R12, R10
MOV.W   MOV.W #0,R11

it would be even better. But this is just nitpicking. Maybe the LRA backend you
are working on will do a better job later. ;-)

- ron

[Bug c/66202] Weird behaviour when fork and printf without newline are being used

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66202

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||tkoenig at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Thomas Koenig  ---
This is a bug tracker for gcc. Your problem appears to be with details of the
interaction of fork() with C's standard I/O, which is more of a general
programming question. Your question would be more appropriate in several other
forums, for example the Usenet newgroup comp.unix.programmer or
stackoverflow.com

[Bug sanitizer/66190] [5/6 Regression] ICE: tree code ‘call_expr’ is not supported in LTO streams with -fsanitize=null

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190

--- Comment #7 from Jakub Jelinek  ---
That looks just wrong. ADDR_EXPR's operand isn't necessarily a decl, testing
TREE_STATIC on random trees can give pretty random answers.
I think what matters is where do we cp_genericize_r the DECL_INITIAL of a
static variable, if that happens, perhaps we should track that case in
cp_genericize_data and not instrument anything in there.

[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752

--- Comment #18 from rguenther at suse dot de  ---
On Tue, 19 May 2015, gil.hur at sf dot snu.ac.kr wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
> 
> --- Comment #17 from Chung-Kil Hur  ---
> Hi Richard,
> 
> I modified the example further.
> 
> #include 
> 
> int main() {
>   int x = 0;
>   uintptr_t xp = (uintptr_t) &x;
>   uintptr_t i, j;
> 
>   for (i = 0; i < xp; i++) { }
>   j = i;
>   /* The following "if" statement is never executed because j == xp */
>   if (j != xp) { 
> printf("hello\n");
> j = xp; 
>   }

Here j is always xp and thus ...

>   *(int*)((xp+i)-j) = 15;

... this can (and is) simplified to *(int *)i = 15; making it the same
testcase again.

>   printf("%d\n", x);
> }
> 
> The above example does not print "hello", so i can assume that "j = xp" is not
> executed.
> However, the program prints "0" instead of "15".
> Can you explain this?

[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts

[gil.hur at sf dot snu.ac.kr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752

--- Comment #19 from Chung-Kil Hur  ---
(In reply to rguent...@suse.de from comment #18)
> On Tue, 19 May 2015, gil.hur at sf dot snu.ac.kr wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
> > 
> > --- Comment #17 from Chung-Kil Hur  ---
> > Hi Richard,
> > 
> > I modified the example further.
> > 
> > #include 
> > 
> > int main() {
> >   int x = 0;
> >   uintptr_t xp = (uintptr_t) &x;
> >   uintptr_t i, j;
> > 
> >   for (i = 0; i < xp; i++) { }
> >   j = i;
> >   /* The following "if" statement is never executed because j == xp */
> >   if (j != xp) { 
> > printf("hello\n");
> > j = xp; 
> >   }
> 
> Here j is always xp and thus ...
> 

Why is "j" always "xp"?
Since "hello" is not printed, "j = xp;" is not executed.
Is there some special semantics of C?
If so, please let me know a reference.

Thanks!

[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752

--- Comment #20 from Marek Polacek  ---
(In reply to Chung-Kil Hur from comment #19)
> (In reply to rguent...@suse.de from comment #18)
> > On Tue, 19 May 2015, gil.hur at sf dot snu.ac.kr wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
> > > 
> > > --- Comment #17 from Chung-Kil Hur  ---
> > > Hi Richard,
> > > 
> > > I modified the example further.
> > > 
> > > #include 
> > > 
> > > int main() {
> > >   int x = 0;
> > >   uintptr_t xp = (uintptr_t) &x;
> > >   uintptr_t i, j;
> > > 
> > >   for (i = 0; i < xp; i++) { }
> > >   j = i;
> > >   /* The following "if" statement is never executed because j == xp */
> > >   if (j != xp) { 
> > > printf("hello\n");
> > > j = xp; 
> > >   }
> > 
> > Here j is always xp and thus ...
> > 
> 
> Why is "j" always "xp"?
> Since "hello" is not printed, "j = xp;" is not executed.

Because that "if (j != xp)" guarantees it.

[Bug ada/66205] New: gnatbind generates invalid code when finalization is enabled in restricted runtime

[simon at pushface dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66205

Bug ID: 66205
   Summary: gnatbind generates invalid code when finalization is
enabled in restricted runtime
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon at pushface dot org
  Target Milestone: ---

Created attachment 35567
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35567&action=edit
Patch to gcc/ada/bindgen.adb

This is on 4.9.1 compiled for arm-eabi on Mac OS X Mavericks (Darwin 13).
Please note that the same problem occurs with 5.1.0.

package System has

pragma Profile (Ravenscar);
pragma Restrictions (No_Enumeration_Maps);
pragma Restrictions (No_Exception_Propagation);
pragma Restrictions (No_Recursion);

and the result of a gprbuild is

gprbuild -p -P testbed
gprbind testbed.bexch
arm-eabi-gnatbind testbed.ali
arm-eabi-gcc -c b__testbed.adb
b__testbed.adb:31:14: "Is_Elaborated" is undefined (more references follow)
gprbind: compilation of binder generated file failed
gprbuild: unable to bind testbed.adb

which happens because bindgen.adb has at :2497

 if not Suppress_Standard_Library_On_Target then
WBI ("   Is_Elaborated : Boolean := False;");
 end if;

but at :408 in the generation of adafinal

  if not CodePeer_Mode then
 WBI ("  if not Is_Elaborated then");
 WBI (" return;");
 WBI ("  end if;");
 WBI ("  Is_Elaborated := False;");
  end if;

I’ve worked out a patch for this, but I’m confused about when to use
Suppress_Standard_Library_On_Target vs Configurable_Run_Time_On_Target vs
Configurable_Run_Time_Mode to determine that adafinal will never actually be
called & hence needn’t do anything.

Not sure whether __gnat_initialize, __gnat_finalize are expected (they aren’t
in the AdaCore arm-eabi libraries), so I’ve suppressed them too.

[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts

[gil.hur at sf dot snu.ac.kr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752

--- Comment #21 from Chung-Kil Hur  ---
(In reply to Marek Polacek from comment #20)
> (In reply to Chung-Kil Hur from comment #19)
> > (In reply to rguent...@suse.de from comment #18)
> > > On Tue, 19 May 2015, gil.hur at sf dot snu.ac.kr wrote:
> > > 
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
> > > > 
> > > > --- Comment #17 from Chung-Kil Hur  ---
> > > > Hi Richard,
> > > > 
> > > > I modified the example further.
> > > > 
> > > > #include 
> > > > 
> > > > int main() {
> > > >   int x = 0;
> > > >   uintptr_t xp = (uintptr_t) &x;
> > > >   uintptr_t i, j;
> > > > 
> > > >   for (i = 0; i < xp; i++) { }
> > > >   j = i;
> > > >   /* The following "if" statement is never executed because j == xp */
> > > >   if (j != xp) { 
> > > > printf("hello\n");
> > > > j = xp; 
> > > >   }
> > > 
> > > Here j is always xp and thus ...
> > > 
> > 
> > Why is "j" always "xp"?
> > Since "hello" is not printed, "j = xp;" is not executed.
> 
> Because that "if (j != xp)" guarantees it.

OK. here is another modification.

#include 

int main() {
  int x = 0;
  uintptr_t xp = (uintptr_t) &x;
  uintptr_t i, j;

  for (i = 0; i < xp; i++) { }
  j = i;

  *(int*)j = 15;

  /* The following "if" statement is never executed because j == xp */
  if (j != xp) { 
printf("hello\n");
j = xp; 
  }

  *(int*)((xp+i)-j) = 15;

  printf("%d\n", x);
}

This program just prints "0".

So we know that "*(int*)j = 15;" is not executed and thus "j == xp" is not
true.

Then, can the following statement change "j" even if the printf is not
executed?

if (j != xp) {
   printf("hello\n");
   j = xp;
}

If not, how can "j == xp" suddenly hold?

[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts

[gil.hur at sf dot snu.ac.kr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752

--- Comment #22 from Chung-Kil Hur  ---
(In reply to Chung-Kil Hur from comment #21)
> (In reply to Marek Polacek from comment #20)
> > (In reply to Chung-Kil Hur from comment #19)
> > > (In reply to rguent...@suse.de from comment #18)
> > > > On Tue, 19 May 2015, gil.hur at sf dot snu.ac.kr wrote:
> > > > 
> > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
> > > > > 
> > > > > --- Comment #17 from Chung-Kil Hur  ---
> > > > > Hi Richard,
> > > > > 
> > > > > I modified the example further.
> > > > > 
> > > > > #include 
> > > > > 
> > > > > int main() {
> > > > >   int x = 0;
> > > > >   uintptr_t xp = (uintptr_t) &x;
> > > > >   uintptr_t i, j;
> > > > > 
> > > > >   for (i = 0; i < xp; i++) { }
> > > > >   j = i;
> > > > >   /* The following "if" statement is never executed because j == xp */
> > > > >   if (j != xp) { 
> > > > > printf("hello\n");
> > > > > j = xp; 
> > > > >   }
> > > > 
> > > > Here j is always xp and thus ...
> > > > 
> > > 
> > > Why is "j" always "xp"?
> > > Since "hello" is not printed, "j = xp;" is not executed.
> > 
> > Because that "if (j != xp)" guarantees it.
> 
> OK. here is another modification.
> 
> #include 
> 
> int main() {
>   int x = 0;
>   uintptr_t xp = (uintptr_t) &x;
>   uintptr_t i, j;
> 
>   for (i = 0; i < xp; i++) { }
>   j = i;
> 
>   *(int*)j = 15;
> 
>   /* The following "if" statement is never executed because j == xp */
>   if (j != xp) { 
> printf("hello\n");
> j = xp; 
>   }
> 
>   *(int*)((xp+i)-j) = 15;
> 
>   printf("%d\n", x);
> }
> 
> This program just prints "0".
> 
> So we know that "*(int*)j = 15;" is not executed and thus "j == xp" is not
> true.
> 
> Then, can the following statement change "j" even if the printf is not
> executed?
> 
> if (j != xp) {
>printf("hello\n");
>j = xp;
> }
> 
> If not, how can "j == xp" suddenly hold?

One more thing.

If you remove the if-statement, then it prints "15" with GCC -O2.

Since "hello" is not printed, I think the if-statement is the same as no-op.
Thus, removing the if-statement should not change the behavior of the program
according to ISO C11.

But, they print different values.

Can you explain this?

Re: [Bug tree-optimization/65752] Too strong optimizations int -> pointer casts

[Andreas Schwab]

"gil.hur at sf dot snu.ac.kr"  writes:

> Since "hello" is not printed, I think the if-statement is the same as no-op.
> Thus, removing the if-statement should not change the behavior of the program
> according to ISO C11.

Unless you are invoking undefined behaviour.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[Bug rtl-optimization/66206] New: Address of stack memory associated with local variable returned to caller

[hiraditya at msn dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66206

Bug ID: 66206
   Summary: Address of stack memory associated with local variable
returned to caller
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hiraditya at msn dot com
  Target Milestone: ---

Clang static analyzer reported this potential bug.
File:   gcc/bt-load.c
Location:   line 234, column 6
Description:Address of stack memory associated with local variable 'x'
returned to caller


220 static rtx *
221 find_btr_use (rtx x, rtx *excludep = 0)
222 {
223 subrtx_ptr_iterator::array_type array;
224 FOR_EACH_SUBRTX_PTR (iter, array, &x, NONCONST)
225 {
226 rtx *loc = *iter;
227 if (loc == excludep)
228 iter.skip_subrtxes ();
229 else
230 {
231 const_rtx x = *loc;
232 if (REG_P (x)
233 && overlaps_hard_reg_set_p (all_btrs, GET_MODE (x), REGNO (x)))
234 return loc; // <-   Address of stack memory associated with local
variable 'x' returned to caller
235 }
236 }
237 return 0;
238 }

[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts

[schwab at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752

--- Comment #23 from schwab at suse dot de ---
"gil.hur at sf dot snu.ac.kr"  writes:

> Since "hello" is not printed, I think the if-statement is the same as no-op.
> Thus, removing the if-statement should not change the behavior of the program
> according to ISO C11.

Unless you are invoking undefined behaviour.

Andreas.

[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts

[gil.hur at sf dot snu.ac.kr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752

--- Comment #24 from Chung-Kil Hur  ---
(In reply to schwab from comment #23)
> "gil.hur at sf dot snu.ac.kr"  writes:
> 
> > Since "hello" is not printed, I think the if-statement is the same as no-op.
> > Thus, removing the if-statement should not change the behavior of the 
> > program
> > according to ISO C11.
> 
> Unless you are invoking undefined behaviour.
> 
> Andreas.

==
#include 

int main() {
  int x = 0;
  uintptr_t xp = (uintptr_t) &x;
  uintptr_t i, j;

  for (i = 0; i < xp; i++) { }
  j = i;

  *(int*)((xp+i)-j) = 15;

  printf("%d\n", x);
}
=

This prints "15".
And I do not think there is any UB.
Please correct me if I am wrong.

Then, I add the if-statement.

==
#include 

int main() {
  int x = 0;
  uintptr_t xp = (uintptr_t) &x;
  uintptr_t i, j;

  for (i = 0; i < xp; i++) { }
  j = i;

  /** begin ***/
  if (j != xp) { 
printf("hello\n");
j = xp; 
  }
  /** end */

  *(int*)((xp+i)-j) = 15;

  printf("%d\n", x);
}
=

This prints "0" without printing "hello".

Thus, this raises no UB unless "j != xp" raises UB.

If you think "j != xp" raises UB, please explain why and give some reference.

Otherwise, I think it is a bug of GCC.

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

--- Comment #28 from Ramana Radhakrishnan  ---
(In reply to chrbr from comment #27)
> > 
> > Should be reproducible without LTO with
> > 
> > int __attribute__((target("fpu=neon"))) main() 
> > {
> > ...
> > }
> > 
> > and compiling without -mfpu=neon.
> > 
> 
> note that #include "arm_neon.h" can't be preprocessed and that the builtins
> are not recognized without a global flag:
> 
> "arm_neon.h:31:2: error: #error You must enable NEON instructions (e.g.
> -mfloat-abi=softfp -mfpu=neon) to use arm_neon.h"
> 
> A further improvement for that might be to set the attribute for all the
> functions defines in  neon.h and remove the #error check.
>   
> e.g:
> 
> __extension__ static __inline float32x2_t 
> __attribute__ ((__always_inline__))
> __attribute__((target("fpu=neon")))
> vadd_f32 (float32x2_t __a, float32x2_t __b)
> {
>   return (float32x2_t) __builtin_neon_vaddv2sf (__a, __b);
> }
> 
> or use a #pragma target (("mfpu=neon")) region.

The #pragma is what I would expect.

[Bug c/66208] New: macro location not detected

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66208

Bug ID: 66208
   Summary: macro location not detected
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manu at gcc dot gnu.org
  Target Milestone: ---

From: https://gcc.gnu.org/ml/gcc-help/2015-05/msg00082.html

void foox (char*, ...) __attribute__ ((nonnull (1)));
#define foo(p) foox (p, "p is null")
#define bar(p) _Static_assert (p, "p is null")

void baz (void) {
  foox (0, "p is null");
  foo (0);
  bar (0);
}

This should print:

test.c:2:16: warning: null argument where non-null required (argument 1)
[-Wnonnull]
 #define foo(p) foox (p, "p is null")
^
test.c:7:3: note: in expansion of macro ‘foo’
   foo (0);
   ^

but for some reason, the input_location at the time of warning is not a virtual
location coming from a macro map. It seems that input_location is not adjusted
correctly before giving this warning 

test.c:6:3: warning: null argument where non-null required (argument 1)
[-Wnonnull]
   (foox (0, "p is null"));
   ^
test.c:7:3: warning: null argument where non-null required (argument 1)
[-Wnonnull]
   (foo (0));
   ^

and it always points to the first location given in the line, which was never
updated to be a macro location.

[Bug rtl-optimization/66206] Address of stack memory associated with local variable returned to caller

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66206

--- Comment #1 from Andrew Pinski  ---
Doubt it unless what is passed in here was a reg rtx which I highly doubt it.

[Bug rtl-optimization/66207] New: Switch alpha to LRA

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66207

Bug ID: 66207
   Summary: Switch alpha to LRA
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Tracker PR to track the progress towards enabling LRA on alpha

[Bug rtl-optimization/66207] Switch alpha to LRA

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66207

Uroš Bizjak  changed:

   What|Removed |Added

   Keywords||ra
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-19
 CC||rth at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
 Depends on||57032
   Target Milestone|--- |6.0
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57032
[Bug 57032] [4.9/5/6 Regression]: internal compiler error: Max. number of
generated reload insns per insn is achieved (90)

[Bug rtl-optimization/66207] Switch alpha to LRA

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66207

--- Comment #1 from Uroš Bizjak  ---
Created attachment 35568
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35568&action=edit
Current middle-end + target enablement patch

Vladimir's patch to enhance simplify_operand_subreg for WORD_REGISTER_OPERATION
targets.

[Bug rtl-optimization/66207] Switch alpha to LRA

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66207

--- Comment #2 from Uroš Bizjak  ---
The patched gcc (the patch from Comment #1) bootstrap went all the way to stage
2, where it crashed on attached source when building libcpp with:

/space/homedirs/uros/gcc-svn/trunk/libcpp/macro.c: In function ‘const
cpp_token* cpp_get_token_1(cpp_reader*, source_location*)’:
/space/homedirs/uros/gcc-svn/trunk/libcpp/macro.c:2568:1: internal compiler
error: Max. number of generated reload insns per insn is achieved (90)

 }
 ^
0x120cfd257 lra_constraints(bool)
/space/homedirs/uros/gcc-svn/trunk/gcc/lra-constraints.c:4379
0x120cdd6fb lra(_IO_FILE*)
/space/homedirs/uros/gcc-svn/trunk/gcc/lra.c:2320
0x120c62b77 do_reload
/space/homedirs/uros/gcc-svn/trunk/gcc/ira.c:5418
0x120c632af execute
/space/homedirs/uros/gcc-svn/trunk/gcc/ira.c:5589
Please submit a full bug report,

The crash can be reproduced with a crosscompiler from x86_64-linux-gnu,
configured with "--target=alpha-linux-gnu --enable-languages=c,c++"

$ cc1plus -O2 -fpreprocessed -o macro.o macro.ii

/space/homedirs/uros/gcc-svn/trunk/libcpp/macro.c: In function ‘const
cpp_token* cpp_get_token_1(cpp_reader*, source_location*)’:
/space/homedirs/uros/gcc-svn/trunk/libcpp/macro.c:2568:1: internal compiler
error: Max. number of generated reload insns per insn is achieved (90)

0xa9b474 lra_constraints(bool)
/home/uros/gcc-svn/trunk/gcc/lra-constraints.c:4379
0xa87e4c lra(_IO_FILE*)
/home/uros/gcc-svn/trunk/gcc/lra.c:2320
0xa49929 do_reload
/home/uros/gcc-svn/trunk/gcc/ira.c:5418
0xa49929 execute
/home/uros/gcc-svn/trunk/gcc/ira.c:5589
Please submit a full bug report,

(gdb) up
#1  0x00a9b475 in lra_constraints (first_p=true) at
/home/uros/gcc-svn/trunk/gcc/lra-constraints.c:4379
4379   MAX_RELOAD_INSNS_NUMBER);
(gdb) p curr_insn
$1 = (rtx_insn *) 0x713d5fc0
(gdb) p debug_rtx (curr_insn)
(insn 973 639 972 89 (set (reg:QI 539 [183])
(reg:QI 183))
/space/homedirs/uros/gcc-svn/trunk/libcpp/macro.c:2566 229 {*movqi}
 (nil))

The end of reload dump shows this sequence:

 Choosing alt 0 in insn 643:  (0) =r  (1) r {zero_extendqidi2}
  Creating newreg=449 from oldreg=183, assigning class GENERAL_REGS to r449
  643: r427:SI#0=zero_extend(r449:QI)
  REG_DEAD r183:QI
Inserting insn reload before:
  883: r449:QI=r183:QI

0 Non pseudo reload: reject++
  alt=0,overall=607,losers=1,rld_nregs=1
0 Non pseudo reload: reject++
alt=1: Bad operand -- refuse
 Choosing alt 0 in insn 883:  (0) =r  (1) rJ {*movqi}
  Creating newreg=450 from oldreg=183, assigning class GENERAL_REGS to r450
  883: r449:QI=r450:QI
Inserting insn reload before:
  884: r450:QI=r183:QI

[Bug rtl-optimization/66207] Switch alpha to LRA

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66207

--- Comment #3 from Uroš Bizjak  ---
Created attachment 35569
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35569&action=edit
Preprocessed source

$ cc1plus -O2 -fpreprocessed -quiet -o macro.s macro.ii

[Bug middle-end/66199] [4.9/5 Regression] lastprivate/linear clause issues on combined constructs

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66199

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Tue May 19 16:16:15 2015
New Revision: 223387

URL: https://gcc.gnu.org/viewcvs?rev=223387&root=gcc&view=rev
Log:
PR middle-end/66199
* tree.h (OMP_TEAMS_COMBINED): Define.
* gimplify.c (enum gimplify_omp_var_data): Add
GOVD_LINEAR_LASTPRIVATE_NO_OUTER.
(enum omp_region_type): Add ORT_COMBINED_TEAMS.
(omp_notice_variable): Accept both ORT_TEAMS
and ORT_COMBINED_TEAMS.  Don't recurse if
GOVD_LINEAR_LASTPRIVATE_NO_OUTER is set and either
GOVD_LINEAR is set, or GOVD_LASTPRIVATE without
GOVD_FIRSTPRIVATE.
(omp_no_lastprivate): New function.
(gimplify_scan_omp_clauses): For OMP_CLAUSE_LASTPRIVATE
and OMP_CLAUSE_LINEAR, if omp_no_lastprivate, don't
notice_outer and set appropriate bits, otherwise make
sure default(none) combined constructs won't complain.
(gimplify_adjust_omp_clauses): Remove OMP_CLAUSE_LINEAR
outer special casing, for OMP_CLAUSE_LASTPRIVATE if
omp_no_lastprivate either remove the clause or turn it
into OMP_CLAUSE_PRIVATE.
(gimplify_omp_for): Fix up handling of implicit
lastprivate or linear iterators.
(gimplify_omp_workshare): For OMP_TEAMS_COMBINED use
ORT_COMBINED_TEAMS.
* omp-low.c (lower_omp_for_lastprivate): For combined
for simd use fd.loop.n2 from the for rather than simd.
gcc/c/
* c-parser.c (c_parser_omp_for_loop): Don't add
OMP_CLAUSE_SHARED to OMP_PARALLEL_CLAUSES when moving
OMP_CLAUSE_LASTPRIVATE clause to OMP_FOR_CLAUSES.
(c_parser_omp_teams): Set OMP_TEAMS_COMBINED for combined
constructs.
gcc/cp/
* parser.c (cp_parser_omp_for_loop): Don't add
OMP_CLAUSE_SHARED to OMP_PARALLEL_CLAUSES when moving
OMP_CLAUSE_LASTPRIVATE clause to OMP_FOR_CLAUSES.
(cp_parser_omp_teams): Set OMP_TEAMS_COMBINED for combined
constructs.
gcc/fortran/
* trans-openmp.c (gfc_trans_omp_teams): Set OMP_TEAMS_COMBINED for
combined constructs.
(gfc_trans_omp_target): Make sure BIND_EXPR has non-NULL
BIND_EXPR_BLOCK.
libgomp/
* testsuite/libgomp.c/pr66199-1.c: New test.
* testsuite/libgomp.c/pr66199-2.c: New test.
* testsuite/libgomp.c++/pr66199-1.C: New test.
* testsuite/libgomp.c++/pr66199-2.C: New test.
* testsuite/libgomp.fortran/pr66199-1.f90: New test.
* testsuite/libgomp.fortran/pr66199-2.f90: New test.

Added:
trunk/libgomp/testsuite/libgomp.c++/pr66199-1.C
trunk/libgomp/testsuite/libgomp.c++/pr66199-2.C
trunk/libgomp/testsuite/libgomp.c/pr66199-1.c
trunk/libgomp/testsuite/libgomp.c/pr66199-2.c
trunk/libgomp/testsuite/libgomp.fortran/pr66199-1.f90
trunk/libgomp/testsuite/libgomp.fortran/pr66199-2.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-openmp.c
trunk/gcc/gimplify.c
trunk/gcc/omp-low.c
trunk/gcc/tree.h
trunk/libgomp/ChangeLog

[Bug target/66201] [avr] ICE in avr_print_operand: Bad address

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66201

--- Comment #1 from Georg-Johann Lay  ---
IMO using operands attached to "m" constraint in the asm template is no valid
avr code.  You can never know the matching instructions because "m" is too
generic: Use LD, LD+ or LDS?

The only valid use of that constraint on avr is to indicate that respective
memory is clobbererd by means of "+m".  To perform the respective change,
however, you'll need the address in a register, i.e. "b" or similar, or you
know in advance that the address is known at link time an may use "s" etc.

Moreover the insn itself is invalid because we don't have DImode support in the
avr backend.

[Bug target/66201] [avr] ICE in avr_print_operand: Bad address

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66201

--- Comment #2 from Georg-Johann Lay  ---
In short: If avr we should skip that test, or at least remove code which is
using that function, e.g. #ifdef __AVR__.